The choice between a self-hosted observability stack and a SaaS platform often gets framed as a matter of principle (control versus convenience), which hides the real calculation: a total cost of ownership, where each option shifts spending to a different line item.
What SaaS actually bills
Observability SaaS platforms (Datadog, New Relic, and others) almost always bill on ingestion: per monitored host, per metric volume, per gigabyte of indexed logs, or some combination of the three. That model has a direct and often underestimated consequence: cost grows with the volume of data observed, independent of business traffic volume or the number of developers using it. Adding a dimension to a metric (a new label value, an additional instrumented service) raises next month’s bill, which creates a quiet but real pressure to under-instrument in order to contain costs.
What self-hosted actually bills
A self-hosted Prometheus/Grafana stack shifts that cost to two different line items: the infrastructure running Prometheus, Grafana, and long-term storage (Thanos, Mimir, or simply extended retention), and operational time, which is never zero. Someone has to size storage, manage version upgrades, arbitrate metric cardinality before it blows up memory consumption, and respond when the monitoring stack itself goes down, a particular kind of incident: the one that prevents seeing every other incident.
The calculation that decides
SaaS almost always wins below a certain volume: for an infrastructure of a few dozen services, the engineering time needed to properly operate a self-hosted stack far exceeds what a proportionate SaaS bill would cost. Self-hosted wins as volume grows, because its marginal cost per additional metric trends toward zero (already-provisioned compute and storage capacity), where SaaS marginal cost stays linear, or worsens at higher pricing tiers. The tipping point depends less on server count than on engineering time already available in-house for operations: a team that already has Kubernetes/Prometheus skills pays a much lower marginal operating cost than one that would need to acquire it specifically for this project.
The hidden SaaS cost the pricing page doesn’t show
A SaaS observability dependency creates a specific risk: if the bill becomes a budget negotiation topic, the easiest short-term option is reducing retention or metric granularity, which silently degrades the ability to diagnose an incident, exactly when the organization is trying to cut costs (often itself a sign of broader strain). Self-hosted doesn’t eliminate that risk, but shifts it: cutting a monitoring infrastructure budget is a more visible decision, generally made deliberately rather than through automatic pricing-tier adjustment.
A third way: hybrid by criticality
Few organizations fully commit to one side. A common pragmatic approach: self-hosted for high-volume, lower-unit-value metrics (infrastructure metrics, verbose application logs), SaaS for a narrow, high-value scope (external monitoring, critical alerting with a contractual availability guarantee the team doesn’t want to own itself). That segmentation requires knowing each option’s real cost against your own volume, not a general preference for one model over the other.
Takeaway
The choice between self-hosted and SaaS observability comes down to total cost of ownership, not ideological preference. SaaS bills ingestion and grows linearly with volume; self-hosted bills infrastructure and operational time, with a marginal cost trending toward zero at high volume if the skill set is already in place. Getting that calculation right before committing to either is part of what gets scoped from the first diagnostic of a reliability and observability engagement.