Sentry pricing explained: plans, quotas, what a startup pays, and what self-hosted Sentry really costs.

The free plan's one-user limit is the real constraint: the moment a second engineer needs to see an issue, you are on Team. Business offers a 14-day trial without a card. Seer, Sentry's AI debugger, is a separate subscription at $40 per active contributor a month on Team and Business, and it does not draw from your pay-as-you-go budget.

Sentry publishes rates per event, such as $0.0003625 per error; we show them per 1,000 or per million so they are easier to read. Two billing rules matter:

• Reserved volume expires monthly. Unused reserved volume does not roll over, so reserve only what you use every month, and cover spikes with PAYG.
• The PAYG budget is shared. One budget covers all categories "on a first-come, first-served basis". A replay or span flood can spend the budget you meant for errors, and once both the reserve and the budget are gone, new data is dropped and not charged.

The second rule is the one to design around: an error storm at 2 a.m. should not leave you blind to the next one. Sections 05 and 07 cover the controls.

Spike protection sets a threshold per project from the last 7 days of hourly volume, at 3 to 6 times the usual level, and drops errors, spans and attachments above it. It is set per project. Turn it on for every project ("Enable All" in Settings, Spike Protection) and turn on its notifications separately, because enabling one does not enable the other. If a spike lasts, it becomes the new baseline, so it slows a runaway bill rather than capping it.

Rate limits per DSN key are the real cap, and they are Business only. Sentry recommends per-minute limits so one bad deploy cannot burn a day's quota in an hour.

We price each tier on the volume inside it, as Sentry's tier tables read. The same usage on Business, billed monthly, is about $673, because errors and spans cost two to three times as much there. That is why a team that moves to Business for SAML should tune first.

Spans and replays are 63% of this bill, and both are set by a sample rate copied from a setup guide.

Lower the trace and replay sample rates, filter browser noise at the door, and switch to annual billing. In the order we'd do it:

1. Turn on every standard inbound filter in each browser project: browser extensions, legacy browsers, web crawlers, localhost, ChunkLoadError and hydration errors. Filtered events cost nothing. On the example this, plus fixing the three noisiest issues, takes errors from 400,000 to about 60,000.
2. Replace tracesSampleRate: 1.0 with a tracesSampler (traces_sample_rate and traces_sampler in the Python SDK). Return 0 for health checks and static assets, 1.0 for sign-up and checkout, and 0.1 to 0.2 for everything else. Errors are still captured at 100%; only tracing is sampled. Spans fall from 66M to about 10M.
3. Record replays on error only. replaysSessionSampleRate: 0 and replaysOnErrorSampleRate: 1.0. You keep a replay for every session that hit an error, which is the one you'd watch.
4. Send logs at info level and above, and keep debug logs in CloudWatch, where you already pay for them.
5. Turn on spike protection for all projects, with notifications.
6. Set a PAYG budget about 50% above a normal month, so a bad week costs a known amount, not an open-ended one.
7. Switch to annual billing once the volume is steady: $26 instead of $29, and reserved volume 20% cheaper than PAYG if you have steady overage.

For the example startup, that is two to three engineer-days to a setup people trust. Two AWS details: tasks in private subnets send events out through your NAT gateway (a small volume, but it is billed per GB processed), and the DSN is not a secret, since browsers see it anyway; the auth token used for source maps is, so keep it in CI secrets only.

Sentry does not replace infrastructure monitoring. It won't tell you an RDS disk is filling or an ECS service is stuck at zero tasks. Keep CloudWatch alarms for that; our production readiness checklist lists the ones that matter at each stage.

When self-hosting is a false economy: almost always, below a SaaS bill of several hundred dollars a month. On the example startup, the hosted Team plan is $56; self-hosted is $255 of AWS plus an engineer's afternoon every month, and a single machine whose failure takes your error tracking down at the moment you need it.

When it makes sense: event data must stay inside your own AWS account (a regulator or a customer contract says so, and Sentry's US or EU regions won't do); you send hundreds of millions of events and the SaaS bill is well into four figures; or you already run a platform team that operates Kafka and ClickHouse. If you only need error tracking, a lighter Sentry-compatible server such as GlitchTip (section 13) is far cheaper to run than the full Sentry stack.

Datadog's bill buys infrastructure monitoring too, though not in this table: that is per host, per container and per custom metric, and our Datadog pricing guide prices a full 10-host startup line by line. We don't repeat those tables here.

When to use which:

• Sentry plus CloudWatch is the seed-stage setup we'd start with: Sentry for "what broke in the code, for whom, since which release", CloudWatch for hosts, queues, databases and alarms. Cheapest, and enough until you have several services calling each other.
• Datadog alone when you want one tool for infrastructure, traces, logs and errors and will pay for it, or you got startup credits. Its error tracking is fine; Sentry's issue grouping, release tracking and frontend tooling are deeper.
• Both is reasonable: Sentry for developers, Datadog for whoever is on call. Keep traces in one of them only, or you pay twice for the same spans.

Switching is easier than it used to be. Datadog accepts events from the Sentry SDK if you point its DSN at Datadog, as a migration path: errors arrive as logs and need Error Tracking for Logs turned on, and traces and attachments are not supported.

On AWS itself there is no direct Sentry equivalent. CloudWatch Application Signals shows latency, faults and errors per service with correlated X-Ray traces, and CloudWatch RUM shows browser errors with stack traces, but neither gives you Sentry's issue workflow: grouping into issues, release tracking, assignees and ownership rules. Many teams use AWS for traces and keep a cheap error tracker for the code. Our OpenTelemetry on AWS guide covers that side.

Lock-in is low by monitoring standards. Sentry's SDK is accepted by GlitchTip and, as a migration path, by Datadog, and Sentry accepts OpenTelemetry traces and logs over OTLP (beta). If you instrument traces with OpenTelemetry and keep Sentry's SDK for errors, you can move either half without touching the other.