Sentry's pricing page shows four numbers: $0, $26, $80, and "custom". Those numbers are accurate, and they are also not what most teams end up paying — because the plan price covers errors, and Sentry bills six other things separately.
This is not a criticism of usage-based billing. It is a reasonable model, and Sentry is a genuinely excellent product. But "we're on the $26 plan" is not the same sentence as "we spend $26", and the gap between them catches people out. Here is the arithmetic.
All figures read from sentry.io/pricing in July 2026. Pricing changes — check the source before making a decision.
The plans
| Plan | Price | What's included |
|---|---|---|
| Developer | $0 | 5k errors · 5M spans · 50 replays · 5GB logs · 1 seat |
| Team | $26/mo billed annually | 50k errors · 5M spans · 50 replays · 5GB logs |
| Business | $80/mo billed annually | 50k errors · 5M spans · 50 replays, plus advanced quotas |
| Enterprise | Custom | Negotiated volume and support |
Note that Team and Business include the same 50k errors. You do not move from Team to Business to get more events — you move for features like advanced quota management, SSO and more granular alerting. Extra volume is bought through overage regardless of plan.
The six other meters
This is where the bill actually moves.
| Meter | Included | Beyond that |
|---|---|---|
| Errors | 50k on Team | ~$0.00025–0.000315 per event |
| Session replays | 50 | ~$0.00375 per replay |
| Logs | 5 GB | +$0.50 / GB |
| Cron monitors | 1 | +$0.78 / monitor |
| Uptime monitors | 1 | +$1.00 / alert |
| UI profiling | — | +$0.25 / hour |
| Continuous profiling | — | +$0.0315 / hour |
Each is a separate line item. Enabling a feature that looks free — replays are "included", after all — starts a meter at 51 recordings.
What actually counts as an event
This is the most common source of a bill nobody can explain, because "event" means three different things depending on which meter you are reading.
An error event is one occurrence of an exception. Not one issue — one occurrence. Sentry groups occurrences into issues in the UI, so a single issue on your dashboard might represent 40,000 billable events. The issue count on screen and the number you are billed for are unrelated, and the dashboard shows you the reassuring one.
A transaction is one traced request or page load. These are sampled, and the sample rate is yours to set. At tracesSampleRate: 1.0 every single page load is a transaction.
A span is a unit of work inside a transaction — a database call, an HTTP request, a render. One transaction routinely contains twenty or more spans, and spans are the meter with the 5M allowance. This is why span volume runs an order of magnitude above error volume, and why trace sampling is the highest-leverage change most teams can make.
A practical consequence: a single noisy issue in a useEffect that fires on every render can generate hundreds of thousands of billable error events while appearing as one row in your issue list. Sorting issues by event count, not by recency, is the fastest way to find what you are actually paying for.
Worked examples
A small app with 80,000 errors a month. You are 30,000 events over the Team allowance. At roughly $0.000315 per event that is about $9.45, so the bill is around $35/month. This is the case where Sentry is cheap and you should probably just pay it.
The same app, with session replay switched on. Replays are where the arithmetic turns. 50 are included; at 10,000 recordings a month you are paying for 9,950 at ~$0.00375, which is about $37/month on top — more than the plan itself. Replay is the single most common source of a surprise Sentry invoice.
A busier app: 500,000 errors a month. 450,000 events of overage at ~$0.000315 is roughly $142, so about $168/month before replays, logs or profiling.
Add a few monitors. Ten cron monitors is +$7.02. Ten uptime alerts is +$10. Individually trivial; collectively the reason the invoice never quite matches the plan page.
How to actually reduce a Sentry bill
If you are staying on Sentry — which, to be clear, is often the right call — these are the levers that work:
- Set per-key rate limits. Most teams' error volume is dominated by a handful of noisy issues. Rate-limiting at the DSN level is more effective than any plan change.
- Filter third-party noise. Browser extensions, ad blockers and injected scripts generate a startling share of frontend errors, and none of them are your bug. Sentry's inbound filters handle the common cases.
- Sample transactions aggressively. Tracing spans are the highest-volume meter by an order of magnitude. Most teams do not need a 100% sample rate to find a slow endpoint.
- Turn replay on deliberately, not globally. Sample it, or trigger it only on error.
- Check what profiling is costing you. Hourly billing is easy to forget about because it does not scale with traffic — it scales with uptime.
What about self-hosting?
Sentry is open source and can be self-hosted, which removes the per-event bill entirely. It is a real option and worth naming, but be honest about the trade: you are swapping a metered invoice for infrastructure you operate. The self-hosted stack is not trivial — Postgres, ClickHouse, Kafka, Redis and a set of workers — and it needs upgrading, monitoring and storage management like anything else you run.
For a team with platform engineers and an existing Kubernetes footprint, that can be clearly cheaper. For a five-person product team, the engineering hours usually cost more than the invoice did. The question is not "is self-hosting cheaper" but "is the cheapest thing here my time".
When the model is the problem
Rate limiting and sampling both work by collecting less data. That is a reasonable trade, and for many teams it is the right one. But it is worth naming what you are doing: paying to reduce your own observability so the invoice stays predictable.
The alternative is a flat price, where volume is not the thing you are managing. That is the model we built Nohmo on — $49/month per project, errors and product analytics together, with no per-event meter. If your error volume is low and you do not need analytics, Sentry Team at $26 is cheaper and we would rather you knew that.
The more interesting difference is not price. It is that a stack trace tells you what broke and never what it cost. Sentry has no funnels, no conversion data and no attribution, so "did this bug lose us signups?" is not a question you can ask inside it. We wrote about how we rank bugs by revenue lost rather than by frequency.
Summary
- Sentry Team is $26/month billed annually and includes 50,000 errors.
- Errors, spans, replays, logs, cron monitors, uptime checks and profiling each meter separately.
- 80k errors ≈ $35/month. Switch on replay at any volume and that can double.
- The effective levers are rate limits, inbound filters and trace sampling — all of which reduce what you collect.