Consolidating Sentry, APM, and logs onto one self-hosted backend: the cost case

The signal from May 2026

PR #266 on jkrumm/free-planning-poker, merged May 19, 2026, removed Sentry from three services (Next.js, Bun/Elysia, and FastAPI) and replaced it with a self-hosted OpenTelemetry stack exporting OTLP to a ClickStack/HyperDX instance already running on the same VPS. The PR description states the motivation directly: "consolidates observability onto one self-hosted backend, gives us real distributed traces."

That PR is the canonical shape of a pattern that has been showing up across small-team repositories this spring. Sentry was the errors backend. APM was a second tool: DataDog, Honeycomb, or Sentry's own Performance product. Logs went to Loki or hosted ELK. Each had its own SDK, its own pricing model, its own retention rules, and its own dashboard URL. Replacing all three with one OTel pipeline landing in ClickHouse is now within reach for a single-VPS deployment, and small teams are doing it.

The same week, a Show HN titled "Torrix, self-hosted LLM Observability (no Postgres, no Redis)" landed on May 13, 2026 with 74 points and 4 comments. The pitch pushed the same idea further: one storage engine, no auxiliary services, the entire observability surface in one place. The two signals are different products solving the same shape of problem, and that is what makes the pattern interesting.

What you pay for in the split-vendor world

Sentry's Team plan starts at $26/month for 50K events, with overages at roughly $0.000295/event after the August 2025 plan changes. Transactions and spans are a separate bucket. Logs are a separate bucket with 5 GB included on every paid plan, then pay-as-you-go from a shared budget.

For a profile of 200K events/month, 5M spans, and 8 GB of logs from three small services, the Sentry-side bill clears about $300/month before any second tool gets added.

Add a hosted APM like DataDog. The infrastructure SKU runs about $31/host/month, and log ingestion is $0.10/GB after the first GB. Three small services plus 30 GB of logs lands in the $130-180/month range.

Add a logs destination if Sentry Logs does not cover everything. Loki Cloud is $0.50/GB ingested, which is roughly $25-60/month for the same volume.

Total at 200K events, 5M spans, 30 GB of logs, and three hosts: $450-540/month, split across three invoices, three dashboards, three SDK init blocks per service, and three SDK upgrade cadences. The dollar number is the visible cost; the per-service init clutter and the three-dashboard context switch are the invisible one.

What unification actually costs

The unified self-hosted version of the same workload needs one VPS, one OpenTelemetry Collector, and one storage engine. The collector is the OTel Collector contrib distribution. The storage is ClickHouse, or ClickStack, which is ClickHouse plus HyperDX bundled. The errors layer is a Sentry-compatible product on the same pipeline: urgentry is one option, Sentry self-hosted is another at much higher RAM cost.

A 4-8 GB RAM, NVMe-backed VPS with 200 GB of disk runs $40-80/month at any major host. The OTel Collector binary is free. ClickHouse is free. HyperDX is free. urgentry is free.

Storage math: 30 GB of logs per month, with default codecs, sits around 3-6 GB on disk after the column compression runs. 5M spans per month compresses to 1-3 GB. Errors are tiny by comparison. A 200 GB disk holds about 18 months of that profile before you need to tighten retention.

Bandwidth: outbound is almost zero because events stay on your VPS. Browser and mobile SDK requests are inbound, which is free at every major host.

The operational tax is not zero. You pay it in hours instead of invoices, and the breakdown later in this guide is where most cost-comparison posts wave their hands.

PR #266 as a worked example

The free-planning-poker codebase has three services. Before the PR: each service initialized a Sentry SDK at boot. The Next.js service used @sentry/nextjs. The Bun/Elysia service used @sentry/bun. The FastAPI service used sentry-sdk[fastapi].

After the PR: each service initializes an OpenTelemetry SDK with auto-instrumentation and exports OTLP/HTTP to the ClickStack/HyperDX endpoint on the same VPS. The Next.js side swapped instrumentation.ts for an otel.ts SDK config plus a tracer.ts helper. The Bun service swapped Sentry.init() for NodeSDK from @opentelemetry/sdk-node. The FastAPI service swapped sentry_sdk.init() for the OpenTelemetry instrumentation entrypoint.

The diff was roughly 200 lines added and 350 removed across config, init, and Docker Compose entries. The largest single removal was the Next.js Sentry config, which is notoriously fiddly across the three places it has to be wired.

What did not survive the swap is worth naming explicitly. Sentry's fingerprint algorithm groups raw exception events into issues so that one bug is one issue, not four thousand events with slightly different stack frames. The OTel side captures exceptions as span events with exception.type and exception.stacktrace attributes, which preserves the raw capture but loses the grouping that makes the issue list readable.

That gap is the place a Sentry-compatible errors layer fits into the same unified pipeline. urgentry accepts OTLP spans flagged as exceptions, applies Sentry-style grouping, and presents the issue-list workflow without requiring a second SDK in the application. The result is one ingest endpoint on the host, one collector pipeline, two product surfaces: HyperDX for traces and logs, urgentry for errors.

Where the three components actually fit

A unified self-hosted observability stack has three layers, and being specific about which piece does what saves time later when something breaks.

Collector. OpenTelemetry Collector, contrib distribution. Receives OTLP from every service, fans out to the storage backends, and handles sampling and PII redaction in the middle. One process, one config file, one upgrade cadence. The contrib distribution covers every receiver and exporter most teams need without writing custom builds.

Storage. ClickHouse, in practice. The OpenTelemetry ecosystem has converged on ClickHouse for traces, logs, and metrics because the column compression and query speed at the storage cost are genuinely hard to beat. ClickStack is the bundled distribution that includes HyperDX as the UI; you can also run ClickHouse on its own and point a different UI at it.

Product layer. This is where the choices spread. HyperDX gives you a Sentry-like UI on top of ClickHouse for traces and logs. Grafana with the ClickHouse data source gives you a BYOD dashboard surface. urgentry handles the errors signal specifically with Sentry-compatible grouping, ingesting either Sentry envelopes or OTLP spans flagged as exceptions. Sentry self-hosted is the heavyweight option if you accept the 16 GB RAM floor (32 GB in practice) and the upgrade treadmill.

Most teams running a unified self-hosted backend end up with two product surfaces, not one. A traces and logs explorer covers the timeline view; an errors product covers the issue list. Trying to force one UI to do both is what makes Sentry self-hosted heavy and what makes a pure-Grafana setup feel undercooked for triage.

The operational tax, with numbers

The reason cost-comparison posts wave their hands here is that the operational tax is real, and it is where the split-vendor model genuinely wins for some teams. Specific numbers help.

The setup hour. First OTel Collector config, first ClickHouse deployment, first HyperDX install, first errors-layer install. For someone who has run none of this before, plan for 4-8 hours of focused work. Half a day with a how-to in the second tab.

The first incident. When the unified stack drops events at 3 AM, you are the on-call. The split-vendor world means Sentry's status page tells you whether the problem is theirs. The unified world means you check disk usage, ClickHouse replica lag, and Collector queue depth yourself. Plan for 4-12 hours over the first six months while you build a runbook from real failures.

Upgrades. A single-binary errors layer like urgentry is a one-line swap, about an hour per quarter including the verification. ClickHouse version bumps on a single node run smoothly, around two hours per minor version. The OTel Collector contrib distribution follows the collector release cadence; breaking changes are rare and well-documented. Call it 6-10 hours per year combined.

Backups. Litestream for SQLite, which is the urgentry default, is two lines of config. ClickHouse on a single node uses its native backup-to-S3-compatible-storage path, about an hour to set up and runs unattended after that. The restore drill is the hour you actually pay for. Do it once when you set things up, document the steps, and forget about it.

Total operational tax for a small team: 30-50 hours over the first year, 10-20 hours per year after that. At $100/hour engineering time, that is $3,000-5,000 in year one and $1,000-2,000 thereafter.

The break-even math at three traffic profiles

Split-vendor at $450/month is $5,400/year. Unified self-hosted at $80/month VPS plus $4,500 in year-one operational time is $5,460. Year two: $80/month VPS plus $1,500 operational equals $2,460. After year one, unified wins by roughly $3,000/year at this profile, and the gap widens with traffic.

Three profiles where the math changes shape:

Profile A: 200K events, 5M spans, 30 GB logs, 3 services
  Split-vendor:  ~$450/month  ($5,400/year)
  Unified:       ~$80/month VPS + $4,500 ops year 1
  Break-even at month 13

Profile B: 1M events, 50M spans, 200 GB logs, 8 services
  Split-vendor:  ~$2,500/month ($30,000/year)
  Unified:       ~$160/month VPS + $4,500 ops year 1
  Break-even at month 4

Profile C: 50M events, 1B spans, 2 TB logs, 50 services
  Split-vendor:  $15K-25K/month
  Unified:       Dedicated SRE plus a $400/month box

The crossover is sharper than most calculators show because the SaaS bill scales linearly with traffic while the VPS bill scales as a step function. You do not pay more for ClickHouse at 50M events versus 200K events; you pay more for the disk and the box. The operational tax is mostly flat once the runbook exists, so the per-event cost trends toward zero as volume grows.

When unification does not pay

Three honest cases where the split-vendor world still wins:

The two-person team with no on-call rotation. If the 30-50 operational hours land on the same person who is shipping product, that is product time you are not getting back. Stay on Sentry SaaS until you have someone whose week the ops time can fit into without displacing feature work. The unification pattern assumes one ops-comfortable person with bandwidth; without that, the math inverts.

A feature no self-hosted product layer has yet. Sentry's Codecov integration, Crons heartbeat alerts, and certain enterprise SAML flows are not fully replicated in the self-hosted ecosystem as of June 2026. If one of those is in the daily critical path, the SaaS bill is buying you something specific. The unification trend is closing these gaps month by month, but it is honest to say the gap is real today.

A compliance constraint that requires an independently-audited observability vendor. Self-hosting inherits your existing SOC 2 boundary, which works for most "data must stay on our infrastructure" requirements. It does not work if the audit requirement is "the observability vendor must be SOC 2 audited as a separate legal entity." That door closes outright, and the right answer is a SaaS vendor.

The unified self-hosted pattern is the right answer for most teams between 5 and 50 engineers, with at least one ops-comfortable person on staff, and traffic above the 200K events/month mark. Below that floor, the SaaS bill is cheap enough that the operational hours never pay back. Above 50 engineers, you have probably already built the platform team that runs all of this anyway, and the question becomes which storage backend rather than whether to self-host at all.

Frequently asked questions