Self-Hosted Observability in 2026: What You Save and What You Pay Instead
Datadog bills per host, Grafana and SigNoz bill per GB, Sentry bills per event. Running it yourself replaces all three with storage and your own time, and the license fine print decides whether you can.
Observability bills grow faster than traffic, and the reason is rarely the vendor. It is that instrumenting more is always the locally correct decision. Every new label, every debug span, every retained log line is defensible on its own, and the aggregate arrives as a surprise once a quarter.
Switching vendors changes the slope of that curve. Cutting what you emit changes the curve itself. It is worth being clear about which one you are doing, because most migrations are sold as the second and deliver the first.
All prices below came off vendor pricing pages on 21 August 2026.
Three units, three different bills
Datadog prices infrastructure per host: $15 per host per month on Pro with annual billing, $23 on Enterprise, and APM stacked on top of that starting at $31 per host. Logs split into ingestion at $0.10 per GB and indexing at $1.70 per million events, which is the line that surprises people, because ingestion is cheap and making those logs searchable is not.
Grafana Cloud prices by volume instead: a free tier with 50 GB of logs, 50 GB of traces, and 10k active metric series at 14 day retention, then a $19 platform fee and per GB rates for processing, writing, and retention. SigNoz Cloud works the same way at $0.30 per GB for logs and traces and $0.10 per million metric samples, from a $49 monthly base.
Sentry prices per event, which is its own category: free for one user with 5k errors and 5M spans, $26 a month for Team, $80 for Business, with logs and metrics overage at $0.50 per GB.
The unit matters more than the rate. A fleet of small containers is expensive per host and cheap per GB. A chatty monolith on four large machines is the opposite. Before comparing prices, work out which shape you are, because that alone can be a two times difference between two vendors quoting similar looking numbers.
What self-hosting actually replaces
Running your own OpenTelemetry backend removes the per host and per GB line items and replaces them with object storage, some compute, and the time of whoever keeps it alive. For a team already operating stateful services, that trade is often good. For a team of four shipping a product, the same trade means the on call rotation now includes the thing that tells you why you are on call.
SigNoz, Grafana’s own stack, OpenObserve, and Uptrace all take OpenTelemetry natively, which means instrumentation is portable between them and between them and the SaaS options. That portability is the strongest argument for standardizing on OTLP regardless of where you land: the collector config changes, the application code does not.
The differences are operational rather than conceptual. Grafana’s components are the most widely deployed and the most work to assemble. SigNoz is the closest to a single product experience. OpenObserve and Uptrace are both AGPL 3.0 and are the lighter options, which matters when the point of self-hosting was to stop operating a fleet of services.
Read the license before you plan the migration
This is the part that gets skipped and then blocks the project in week three.
Sentry is under the Functional Source License 1.1 with an Apache 2.0 future license, not an OSI approved open source license. You can run it yourself, and you cannot build a competing hosted product on it until the future license kicks in.
SigNoz, PostHog, and Bugsink each ship a mixed license tree: a permissive core with an enterprise directory under commercial terms. That is a perfectly workable arrangement, and it means the feature you are counting on might be on the wrong side of the line. Check the specific directory, not the repository badge.
Grafana, OpenObserve, and Uptrace are AGPL 3.0, which is genuinely open source and genuinely has obligations if you expose a modified version over a network. For internal use that is a non issue. For anything customer facing built on top, ask someone who reads licenses for a living.
The eBPF shortcut, and its limit
Tools like Coroot and Odigos, both Apache 2.0, attach instrumentation through eBPF rather than through code changes, which gets you service maps and request level metrics without touching an application. For a legacy service nobody wants to redeploy, or for a first pass across a cluster where nothing is instrumented, that is a real shortcut.
What it does not give you is domain context. eBPF sees a request between two services; it does not see that the request belonged to a batch import for one specific tenant. Auto instrumentation gets you to the service that is slow. Manual spans get you to the reason. Most teams end up wanting both, and starting with eBPF is a reasonable way to buy time.
Cutting the bill without changing vendors
The three reliable savings are the same everywhere, and none of them require a migration.
High cardinality labels are the usual culprit on metrics. A user ID or a request ID as a label multiplies series count by your user base, and per series pricing turns that into a bill immediately. Find the top few offenders and drop them; the dashboards almost never used them.
Tail sampling on traces keeps the errors and the slow requests and throws away the boring successful ones. Keeping 100% of traces is a decision most teams never consciously made.
Retention is the quietest one. Very few investigations reach back more than two weeks, and both Grafana Cloud and SigNoz price retention as its own line. Shortening it is a config change with a same day effect on the invoice.
Do those three first. If the bill is still wrong afterward, then the vendor or the hosting model is genuinely the problem, and you will be migrating with a smaller and better understood pile of telemetry, which is a much easier migration than the one you would have run before.