Self-Hosted Observability vs Managed

Every team storing telemetry eventually makes the same call: run the storage and query layer yourself, or pay someone to run it. The trade is not really cost versus convenience. It is which failure modes you would rather own, because both options have them and they are different failure modes.

Before the framework, the disclosure that should shape how you read it: TracePath is a managed product and there is no self-hosted edition of it. So this is not a neutral source. What follows tries to be a useful one anyway, by being specific about when self-hosting is the right answer and about what the managed option actually does and does not include.

Key takeaways

• The decision is about who carries the pager for the observability stack, not about license cost.
• Self-hosting wins on data residency, on air-gapped or regulated networks, and when you already have platform engineers with spare capacity.
• Managed wins when observability is not a thing your team wants to be good at, and when you need retention, backups and upgrades to be somebody's contractual problem.
• The lock-in you should worry about is instrumentation, not storage. OpenTelemetry removes it, and it removes it on both paths.
• Whichever you choose, decide your retention policy before you choose. It is the single biggest cost driver on either side.

What self-hosting observability actually means

"Self-hosted" is rarely one thing. In practice it is a stack, and the component list is the honest starting point for any cost comparison:

• Ingest: an OpenTelemetry Collector fleet, or per-signal receivers.
• Trace storage and query: something that can hold spans and reassemble a trace across services.
• Metric storage: a time-series database, plus whatever handles downsampling and long-term retention.
• Log storage: an index, or an object-store-backed log engine.
• A query and dashboard layer on top of all three.
• Alerting and paging, which is a separate system again in most stacks.
• Object storage underneath, usually S3-compatible, for anything retained beyond the hot window.

You can assemble that from mature open-source components, and plenty of teams do. The point is that the shape of the bill is not "one VM". It is several stateful services, each with its own upgrade path, its own resource profile and its own way of falling over.

The cost that is not the VM

Compute is the part that is easy to price and the part that rarely dominates. These are the costs that show up later:

Cost	Why it bites
Storage growth	Telemetry grows with traffic and with instrumentation coverage. A team that adds tracing to three more services can double ingest without any traffic change.
Cardinality incidents	One new high-cardinality label, a user ID on a metric, a request ID in a log index, can take a metric store down. This is the single most common self-hosted outage.
Retention decisions	Keeping 90 days of raw spans is an order of magnitude more storage than keeping 7. Nobody writes the policy until the disk fills.
Upgrades	Stateful services with on-disk formats. Multiply by the number of components in the stack, times however often you actually apply them.
The pager	Observability is what you use to debug an outage. When it is down during one, you are debugging blind. That makes it tier-1 infrastructure whether you planned for that or not.
Expertise concentration	These systems tend to have exactly one person who understands them. That person eventually takes a holiday, or another job.

None of this makes self-hosting wrong. It makes "it is just a VM and some disk" wrong. Price the second column, not the first.

When self-hosting genuinely wins

• Data residency or air-gap requirements that no vendor contract satisfies. If telemetry legally cannot leave your network, the decision is already made.
• You already run stateful infrastructure well. If you operate your own databases and have a platform team with an on-call rotation, the marginal cost of one more stateful system is much lower than the sticker price suggests.
• Volume so high that per-GB pricing dominates everything else. There is a crossover point where engineering time is cheaper than ingest. It is higher than most teams estimate, but it is real.
• You need to modify the stack. Custom storage backends, unusual retention tiering, integration with an internal system nobody else has.
• Predictable, flat cost matters more than elasticity. Fixed hardware and a known ceiling, rather than a bill that tracks a traffic spike.

When managed wins

• Observability is not a product your team ships. Every hour spent tuning a metric store is an hour not spent on what your customers pay for.
• The team is small. Below a certain size there is no "platform team", there is a person who also does everything else.
• You want the stack to be reliable when your own is not. A separate operator, separate infrastructure, separate failure domain.
• Backups, upgrades and retention need to be someone's obligation, not someone's intention.
• You need the surrounding product, not just storage: grouping and deduplicating exceptions, symbolicating minified traces, session replay, on-call schedules, status pages. Each of those is its own project to build.

The decision table

Question	Leans self-hosted	Leans managed
Can telemetry leave your network?	No	Yes
Do you already operate stateful services on-call?	Yes	No
Who owns the observability pager?	A named team	Nobody yet
Monthly ingest volume	Very large and growing	Small to moderate
Retention requirement	You want full control of tiering	Plan tiers are fine
Cost shape you prefer	Fixed capacity	Usage-tiered subscription
Time to first useful dashboard	Weeks	Hours
Who fixes it at 03:00?	You	The vendor

If the answers split evenly, that usually means the real constraint has not been named yet. Find it before you start building.

The lock-in question

Teams choose self-hosting to avoid lock-in and often misidentify where the lock-in lives. It is almost never in the storage. It is in the instrumentation: the vendor SDK compiled into every service, the proprietary span format, the agent that only talks to one backend. That is what makes leaving a six-month project instead of a config change.

OpenTelemetry is the answer to that, and it works the same on both paths. Instrument with OTel SDKs and auto-instrumentation, export OTLP, and your backend becomes an endpoint and a header. Moving to a different backend, or exporting to two at once while you evaluate, is an exporter edit rather than a rewrite.

TracePath's entire integration surface is that endpoint and that header, by design. There is no TracePath SDK to install and no wrapper to learn, which is also why a service already exporting OTel needs no new dependency at all. If you later decide to run your own stack, the instrumentation you wrote comes with you.

What does not travel, on any platform, is historical data. Telemetry is high-volume and time-boxed, so the practical migration is dual export: send to both backends for one retention window, then cut over. Plan for that rather than for a backfill.

Where TracePath sits

TracePath is a commercial, hosted product operated by AtlasAPX Kamil Krawczyk, a sole proprietorship registered in Poland, under Polish law. There is no self-hosted edition and no community edition. What it gives you in exchange:

• One backend for logs, traces, metrics, exceptions, session replay, profiles, AI tracing, synthetic monitors, status pages and on-call paging, so those are not seven systems to integrate.
• Standard OTLP ingest at https://ingest.tracepath.dev/api/otel, so the instrumentation is portable.
• Plans from EUR 0: Free at EUR 0, Pro at EUR 29 per month or EUR 290 per year, Business at EUR 99 per month or EUR 990 per year, all excluding VAT. Yearly billing is twelve months for the price of ten. Enterprise is a conversation.
• Quotas that stop rather than surprise you. Every plan has a monthly ingest allowance. At 80% the organization's owners get a warning email. At 100% ingest pauses: TracePath answers 503 with a Retry-After header until the next period or an upgrade, which every OTLP exporter and Collector retries correctly. There is no overage billing, so a runaway debug log cannot produce an invoice nobody approved.
• Your data stays yours. Nothing about the instrumentation ties you to us: you send plain OTLP, so leaving is a change of exporter endpoint, not a re-instrumentation project. Dashboards export and import as JSON, stored telemetry is readable through the documented query API with a personal access token, and a self-serve bulk export is on the roadmap — today you can also ask support and we produce a full export within 30 days at no charge.
• Enterprise terms for the paperwork cases: custom limits and retention, invoicing, a countersigned DPA and a named support contact.

Two things it deliberately does not claim. It is not certified against SOC 2 or ISO 27001, and it is not HIPAA-compliant: there is no BAA on offer today, so do not send protected health information. What is actually implemented is written up on the security page, and the third parties involved in running the service are listed on the subprocessors page.

The full limits per plan, projects, seats, ingest, retention and monitors, are on the pricing page.

How to evaluate without committing

1. Instrument with vendor-neutral OpenTelemetry first. Do this before you pick a backend. It is the step that keeps every later decision cheap.
2. Run a collector in front. One place to change the exporter, and the ability to fan out to two backends at once.
3. Send one real service, not a demo app. The questions that matter, cardinality, attribute hygiene, whether your log bridge is wired up, only show up with real traffic.
4. Write the retention policy down. How long do you need spans, logs and metrics? The answers are usually different, and they decide the cost on either path.
5. Measure your actual monthly volume before comparing prices. Most teams guess high by a factor of several, then buy for the guess.

FAQ

Can I self-host TracePath? No. TracePath is a hosted product only; there is no self-hosted or community edition to install. If self-hosting is a hard requirement, one of the open-source stacks is the right answer for you, and your OpenTelemetry instrumentation will work with them.

Is TracePath open source? No. It is closed-source commercial software. It is built on open standards, OpenTelemetry and OTLP, which is what keeps your instrumentation portable, and the third-party open-source components it builds on are credited on the licenses page.

What happens if I exceed my plan's ingest allowance? You get a warning email at 80% of the monthly allowance. At 100%, ingest pauses with a 503 and a Retry-After header until the period rolls over or you upgrade. Nothing is billed as overage.

How do I move my instrumentation somewhere else later? Change the exporter endpoint and header. Everything else is standard OpenTelemetry. For the history already stored: dashboards export as JSON, the query API reads stored telemetry with a personal access token, and support produces a full export on request within 30 days. Overlap the two backends for one retention window instead of planning a backfill.

Is a self-hosted stack cheaper? At small volume, almost never, once you count the time. At very large volume, frequently. The crossover depends on your retention policy and on what your engineering hours are worth, which is why the retention question belongs before the pricing question.

Next

• What TracePath includes, plan by plan
• OpenTelemetry-native ingest and logs on the same pipeline
• Running a Collector in front of TracePath
• TracePath compared with a self-run Grafana stack
• Exporting your telemetry — what leaves the account and how