When self-hosting error tracking saves money — and when it doesn’t.

The math everyone runs and the math nobody runs

The cost comparison everyone runs looks like this: Sentry SaaS at $X per month versus a VPS at $Y per month. X is larger than Y. Self-hosting wins.

The comparison nobody runs looks like this: Sentry SaaS at $X per month versus (VPS at $Y per month) plus (engineer hours at Z hours per month times hourly rate). That second calculation often reverses the result.

The SaaS bill is the visible number because it shows up on a credit card statement. The engineer-hour cost is the invisible number because it hides inside salaries, inside “ops work,” inside “things we handle anyway.” It is real cost. The engineer who spends two hours troubleshooting a Kafka restart is not spending two hours on the product. The invoicing system does not capture that, but the product timeline does.

Self-hosting is the right call for a specific set of conditions. Those conditions exist. I will describe them. But leading with “self-host and save money” without running both calculations is financially irresponsible advice, and most of the internet gives exactly that advice.

The engineer-hour assumption

Let’s anchor on a number. An engineer at a Series A or B company in 2026 costs roughly $150/hour all-in: salary, benefits, payroll taxes, employer costs, office overhead. That is a median for backend engineers in North America; adjust it downward for distributed teams or regions with lower labor costs, upward for principal or staff levels.

The self-hosted Sentry Docker Compose stack takes 4–8 hours per quarter for routine maintenance: pulling updated images, watching ClickHouse and Kafka disk usage, investigating OOM events, restarting containers. Call it 6 hours per quarter, which is 24 hours per year. At $150/hour, that is $3,600 per year in ops time.

Sentry Business SaaS costs roughly $26–80/month depending on team size and plan tier, before overages. At $40/month, the annualized bill is $480. At $80/month, it is $960.

So: 24 hours per year of routine ops time, which does not feel like much in isolation, already costs more than an entire year of the SaaS plan. The ops time has to be zero for the SaaS comparison to be unfavorable at low event volume, and it is never zero.

Major upgrades are on top of routine maintenance. The getsentry/self-hosted issue tracker documents upgrade windows that last 8 hours when things go well and multiple days when a ClickHouse schema migration stalls or a Kafka topic structure changes. One 8-hour upgrade per year at $150/hour is another $1,200. A bad upgrade costs $2,400 or more. Now you are at $4,800–6,000 per year in ops time before a single incident fires. That exceeds the Sentry Business bill for most small teams even before you add VPS hardware.

The point is not that self-hosting is always wrong. The point is that the ops-time line has to appear in the calculation, with a real number, before the comparison is honest.

Where the SaaS bill grows faster than the engineering work

The self-hosting case is real in the conditions where the SaaS bill runs away from your event volume much faster than the operational overhead of self-hosting grows. Three specific situations produce this pattern.

High event volume. Sentry SaaS bills per error event above the included quota. Teams processing 50 million or more events per month pay overage rates that compound quickly. At that volume, the infrastructure and ops time of self-hosting become favorable even at AWS pricing. The break-even is not a small-team number; it is a company-with-real-traffic number.

Session replay at scale. Sentry charges per replay session. A product with 500,000 monthly active users at 10% session sampling generates roughly 50,000 replays per month. The overage rate applies after the included quota. At sufficient MAU and a moderate replay sampling rate, the replay line item alone can exceed the full self-host infrastructure cost for the month.

Span volume after the August 2025 quota cut. In August 2025, Sentry halved the included span quota from 10 million to 5 million per month on Team and Business plans. Teams with broad distributed tracing instrumentation saw their effective per-span cost double without changing any code. A service handling 200 requests per second with 40 spans per transaction generates roughly 20 billion spans per month. That team is nowhere near the included quota. Span overage is now the fastest-growing line item on many mid-stage company Sentry bills.

Multi-region deployment with data residency requirements. If your compliance regime requires that telemetry stay in a specific geography, Sentry SaaS can accommodate some of those requirements, but a self-hosted deployment with your own geographic footprint gives you direct control at no incremental license cost. When the SaaS bill for a multi-region setup includes premium features or enterprise contracts, the gap widens.

Where the engineering work grows faster than the SaaS bill

There is an equally real set of conditions where self-hosting starts cheap and becomes expensive as requirements grow.

Multi-AZ high availability. A single-node self-hosted deployment is fine until it is not. A team that needs 99.9% uptime SLA on their error tracker needs redundant nodes, a load balancer, replicated storage, and failover logic. That multiplies infrastructure cost and ops complexity simultaneously. Sentry SaaS has multi-AZ infrastructure included.

Backup discipline that actually gets tested. Taking backups is easy. Having a backup that you have actually restored from, under time pressure, at 11pm, is different. Self-hosted error tracking demands the same backup rigor as any production database, but it is often treated as a second-tier concern. ClickHouse backup and restore is not trivial. SQLite backup is simpler but still requires a process and a test schedule.

Audit-log SIEM integration. A compliance team that needs error-tracker access logs integrated into a SIEM requires either purchasing the Sentry Enterprise plan or building the integration yourself from the self-hosted stack. The latter is not a small project.

SOC 2 evidence collection. If your company pursues SOC 2 Type II, your error tracker is a scoped system. Self-hosting means you are responsible for the access controls, the logging, the change management, and the audit evidence for that system. Sentry SaaS provides compliance documentation and controls you can inherit. You cannot inherit controls from a stack you run yourself.

Each of these is a multiplier on the engineering work side of the equation. They do not kick in for every team, but teams that hit more than one of them tend to find that the self-host total cost of ownership grows faster than they expected.

The single-binary case

There is a version of self-hosting where the ops-time argument is much smaller. It is worth separating this from the Sentry Docker Compose case because the math is genuinely different.

urgentry is a Go single binary. It uses SQLite by default. Postgres is optional for larger deployments. Under sustained load at 400 events per second, it sits at roughly 52 MB resident memory. A $5 VPS with 1 vCPU and 1 GB RAM runs it. A $10–20 VPS gives comfortable headroom for most small to mid-size teams.

The ops story for a single binary is qualitatively different from the ops story for a 20-container Docker Compose stack. There are no JVM processes to tune, no Kafka log retention to manage, no ClickHouse schema migrations to survive. An upgrade is a binary swap plus a smoke test. Routine maintenance is checking that the process is running and that disk is not filling up. At $150/hour, 30 minutes per month for maintenance and 30 minutes per year for an upgrade totals roughly $1,500/year in ops time. That is less than half the ops time for the Sentry self-hosted stack.

The breakeven point for urgentry self-hosted versus Sentry SaaS is much lower than the breakeven for Sentry self-hosted. A small team with a modest Sentry bill around $60–80/month can credibly shift to urgentry self-hosting and come out ahead in total cost of ownership once event volume exceeds a few hundred thousand per month.

The honest caveat: urgentry does not have the full Sentry product surface. Session replay is present but with a partial playback experience. Deep performance profiling product surfaces are narrower. If those are core to your workflow, urgentry is not the right call and the comparison stops there. Check the compatibility matrix before drawing any conclusions.

The Sentry self-hosted case

Sentry’s self-hosted distribution is the genuine article: the same application that runs Sentry’s cloud product, with the full feature surface. The license is FSL-1.1-Apache-2.0, which converts to Apache 2.0 after two years. The ops story is where the gap appears.

The getsentry/self-hosted README documents a 16 GB RAM minimum. Operators on the issue tracker document needing 24–32 GB in practice. ClickHouse alone claims 8–12 GB under real ingest. Kafka and ZooKeeper together baseline at 2–4 GB. The rest of the 20-container stack adds the remainder. A 16 GB host runs the stack at idle; it runs out of headroom under real production load within days.

A 32 GB VM on Hetzner (the cheapest credible option for EU data residency) costs roughly $60–65/month. On AWS, you are looking at $170–280/month depending on reserved versus on-demand pricing. That is the hardware floor.

The install.sh script pins container versions. Minor updates apply cleanly in most cases. Major upgrades are where the documented pain concentrates. The getsentry/self-hosted issue tracker contains a long-running thread on upgrade failures, migration stalls, and rollback procedures. Operators who have been burned by a bad upgrade tend to add a pre-migration testing environment to the process, which adds time. One bad upgrade per year can cost 2–3 days of engineering time.

This is where the engineer-hour math goes sideways most often. The 24–48 hours of upgrade time at $150/hour plus routine quarterly maintenance at $3,600/year plus a 32 GB VPS at $720–3,360/year produces a total cost of ownership in the $5,000–8,000/year range in a normal year. In a year with a rough upgrade, that number can reach $10,000+. Sentry Business SaaS at 5 million events per month costs less than $600/year.

The Sentry self-hosted case is real, but it requires the conditions to match: existing SRE capacity that already runs Kafka and ClickHouse, hardware already available, event volume above 50 million events per month. Below those conditions, the math rarely closes.

Three teams where self-host wins

A 20-person SaaS with steady event volume. Five million errors per month, 10 million spans, 20,000 replays. Sentry Business at that volume costs roughly $570/month, or $6,840/year. This team has a backend engineer who manages their Kubernetes cluster and has done so for two years. Adding urgentry to the cluster is roughly 4 hours of setup and 30 minutes per month of ongoing work. Annual self-host TCO: $720 VPS plus $900 ops time at $150/hour. Savings: roughly $5,200/year. The math closes.

A regulated team with data residency requirements. GDPR, HIPAA, or a data processing agreement that prohibits sending application error events to a US-based SaaS. Self-hosting is not a financial decision for this team; it is a compliance decision. When the constraint is hard, cost is secondary. The right question is which self-hosted option produces the lowest total cost of ownership within the constraint, not whether to self-host at all.

A team already running its own Kubernetes cluster. A company with a dedicated platform engineering team and existing Kubernetes infrastructure can add urgentry or Sentry self-hosted as a managed deployment to their existing cluster. The marginal ops cost is low because the foundational work (monitoring, alerting, certificate management, backup pipelines) already exists. The infrastructure cost is absorbed into the existing cluster budget. The financial case is strong.

Three teams where self-host loses

A 3-person seed-stage startup with no ops capacity. The CTO builds the product and handles infrastructure. Their Sentry bill is $40/month. Self-hosting Sentry requires a 32 GB VM, Docker Compose expertise, Kafka familiarity, and a backup process the team has actually tested. None of those exist yet. The first upgrade takes a weekend. The savings are $480/year. The cost in founder time is several times that, and the opportunity cost of not building the product is higher still.

A team whose error volume is sporadic enough to stay inside the free tier. Sentry’s free tier at 5,000 errors per month is genuinely free. A team building an early-stage product with low traffic has no SaaS bill to replace. Self-hosting adds ops overhead for zero financial benefit. The free tier exists; use it.

A team that already pays for Datadog and gets error tracking bundled. Datadog Error Tracking arrived as part of the Datadog APM and Log Management bundle. Teams already paying for Datadog APM at scale sometimes find that error tracking is effectively included in what they already pay. Adding a self-hosted Sentry stack to get something they already have makes no financial sense. The same applies to teams using New Relic Errors Inbox or Honeycomb’s error surface.

The midcase nobody talks about

There is a trajectory that the internet rarely describes because it does not fit either the “self-host everything” or the “SaaS is always right” narrative: you self-host for the first two years, then move back to SaaS as the company grows past its operational appetite.

This is a reasonable and reversible decision. A 10-person team with one backend generalist can handle urgentry self-hosting at 30 minutes per month. When that team grows to 50 people, the SaaS bill at higher event volume is still manageable, but more importantly, the company now has an ops team whose time is worth more on other things. Moving back to Sentry SaaS involves updating one DSN configuration line per service. The historical issue data stays in the old instance until retention expires; new events start flowing to Sentry immediately.

The decision is not permanent. Teams that treat it as permanent make worse decisions than teams that treat it as a current-economics calculation that should be revisited annually. The right question is not “should we self-host?” The right question is “should we self-host right now, given our current team size, ops capacity, event volume, and SaaS bill?”

A worked example

The same workload run three ways: 5 million errors per month, 10 million spans per month, 20,000 replays per month. A 20-person engineering team. $150/hour all-in engineer cost. Hetzner as the self-hosted provider.

A few notes on the numbers. The Sentry self-hosted ops time uses 1.5 hours per month as a monthly average, which reflects 6 hours per quarter of routine maintenance. The annual upgrade is estimated at 10 hours (a clean upgrade year); a rough year would be 24–40 hours, pushing the Sentry self-hosted annual total past $7,000. The urgentry routine maintenance estimate is conservative at 30 minutes per month; a team that checks the monitoring dashboard weekly and has alerts configured can do less.

At this workload, urgentry self-hosted is roughly $5,500/year cheaper than Sentry Business SaaS and roughly $3,700/year cheaper than Sentry self-hosted. The surprise is that Sentry self-hosted does not save as much as it appears to. The hardware savings are real, but the ops-time cost at this volume almost closes the gap with the SaaS bill.

The answer

It depends. But “it depends” is not useful without the variables.

What is your actual Sentry bill, annualized? Pull three months of invoices. Take the average. Multiply by twelve. If you are projecting because you are not on Sentry yet, build a model using your anticipated error, span, and replay volume against the current Sentry pricing page. That number is the thing you are comparing against.

What is your honest ops time estimate? Who on your team would own the self-hosted deployment? How many hours per month does that person currently spend on infrastructure work? How many hours would urgentry or Sentry self-hosted add? Multiply by your all-in hourly rate. Do not use zero. Do not use the best-case estimate. Use the number you would use if you were billing a client for the same work.

Which self-hosted option fits your team? A team with no existing ops capacity should evaluate urgentry, not Sentry self-hosted. The ops-time difference between a single binary and a 20-container Docker Compose stack is large enough to change the conclusion. A team with SRE capacity that already runs Kafka and ClickHouse for other services has a different calculus.

Run the comparison with both sides of the ledger populated. Include ops time with a real rate. Include the upgrade cost. Compare the total to the SaaS bill. The decision becomes clear in most cases when the math is complete.

Frequently asked questions