The PAYG bill from one buggy deploy: modeling Sentry overage math

The PAYG model in 2026: per-unit overages by category

Sentry's PAYG budget is one number on a slider in billing settings. Under it sit six separately-metered categories that share the pool. When any one of them runs past its included quota, the overage drains the same budget the others depend on.

The published per-unit rates as of mid-2026, paid in PAYG dollars once the included quotas are gone:

• Errors - about $0.000176 per error event on the Team plan (a hair higher on Developer, lower in volume tiers on Business).
• Spans - about $0.0000054 per span after the August 2025 pricing change that cut the per-span rate roughly in half. Transactions are gone as a line item; spans are billed individually.
• Replays - about $0.0029 per session. This is the line item that moves bills the fastest when replays are sampled on errors.
• Profile hours - about $0.025 per profile hour for continuous profiling. A four-worker fleet profiling at 50% sampling rate runs roughly 1.4 profile hours per wall-clock hour per worker.
• Attachments - about $0.30 per GB. Source maps and dSYMs are stored outside this line item (debug files have their own retention model); this rate applies to event-attached binaries and screenshots.
• Logs - about $0.50 per GB above the 5 GB included floor that GA'd in the August 2025 plan change. The Sentry Logs pricing piece walks the floor calculation for a real service.

Rates drift. Pull them off the live sentry.io/pricing page before you commit any specific scenario to a board doc. The model that follows uses the figures above as the working approximation.

Anatomy of a buggy deploy flood

A flood is the product of three numbers: request rate, error-per-request rate, and the time between deploy and rollback. The first is whatever traffic looks like at that moment. The second is whatever the bug does. The third is whatever your on-call response time happens to be on a Sunday at 7 PM.

The three lines that matter for the bill are not just the error count. A modern Sentry SDK with sensible defaults captures, for one failed request:

• One error event (always).
• The transaction with whatever spans were instrumented during the request - typically 8 to 15 for a Rails or Django request that hits a database, a cache, and a downstream service.
• One replay session, if replaysOnErrorSampleRate is set above zero (most teams set it to 1.0 because the whole point is "I want a replay when something breaks").
• Optional profile hours, if continuous profiling is on for the worker that handled the request.

The error event is the cheapest line item. The replay is the most expensive per failed request. The spans are the largest count. The bill comes out of the multiplication, not the addition.

Three deploy-flood scenarios, walked end to end

Scenario A: the modest service (120 req/s, four minutes to rollback)

A mid-traffic API service running 120 requests per second. A bad migration ships at 7:02 PM. Every request hits the broken codepath. The on-call sees pages at 7:03, rolls back at 7:06. Four minutes of flood.

Errors:    120 × 240        =     28,800 events × $0.000176 = $5.07
Spans:     120 × 240 × 10   =    288,000 spans  × $0.0000054 = $1.56
Replays:   28,800 × 0.25    =      7,200 sessions × $0.0029  = $20.88
Total overage on the flood window:                            ~$27.51

Twenty-seven dollars hidden inside a four-minute window most teams would call uneventful. Notice the replay line: at a 25% on-error sampling rate (a common starting point), replays are already the dominant cost even though the count is the smallest of the three. If replaysOnErrorSampleRate is set to 1.0, the replay column triples to $83 and the total clears $90.

Scenario B: the bigger service (500 req/s, four minutes to rollback)

The same shape, larger surface. 500 req/s, the bug fires on 100% of requests, four-minute rollback.

Errors:    500 × 240        =    120,000 events × $0.000176 = $21.12
Spans:     500 × 240 × 12   =  1,440,000 spans  × $0.0000054 = $7.78
Replays:   120,000 × 0.25   =     30,000 sessions × $0.0029  = $87.00
Profile:   continuous profiling on 4 workers, 4 min, 50% rate ≈ 0.13 hr × $0.025 = $0.003
Total overage on the flood window:                           ~$115.90

Spans look small relative to their volume - that is the August 2025 cut at work. Replays look enormous relative to their count. At 100% on-error replay sampling, this scenario crosses $350 in four minutes.

Scenario C: the webhook retry loop (2,000 req/s, eight minutes to pager fire)

This is the one that ends up on Hacker News. A webhook handler that fails open and retries on every failure. Each inbound webhook becomes five attempts. The bug ships at 2:14 AM, the on-call's phone rings at 2:22. Eight minutes of compounding flood.

Errors:    2,000 × 480       =    960,000 events × $0.000176 = $168.96
Spans:     2,000 × 480 × 15  = 14,400,000 spans  × $0.0000054 = $77.76
Replays:   960,000 × 0.10    =     96,000 sessions × $0.0029  = $278.40
Logs:      structured logging on the failing path, ~12 GB     × $0.50 = $6.00
Attachments: stack-context blobs averaging 5 KB on every error
            = ~4.6 GB                                         × $0.30 = $1.38
Total overage on the flood window:                          ~$532.50

$532 from one bad webhook handler. Push replaysOnErrorSampleRate to 1.0 and the replay column alone clears $2,780. Add the kind of attachments a debug build sends (full request bodies, base64 screenshots), and four-figure totals stop being theoretical.

The shape that surprises operators is not the magnitude. It is which line item dominates. Errors look like the headline number on the dashboard but spans and replays carry the bill. The first time a team sees this in practice, the line they cut first is usually the wrong one.

Spike Protection and the PAYG cap: what they actually do

Sentry has two mechanisms that sound like they should make the scenarios above impossible. Neither one actually does.

Spike Protection, documented at docs.sentry.io/pricing/quotas/spike-protection/, watches per-hour ingest of errors and transactions. When it detects a surge that exceeds a learned baseline (typically a multiple of the previous days' median for that hour), it caps ingest for the remainder of the hour. Three things to know about it:

• It is not retroactive. Events accepted during the surge-detection window are billed normally. By the time Spike Protection trips, the first one to ten thousand events of the flood are already on the bill.
• It does not cover replays, profile hours, attachments, or logs. Those categories have separate quotas and no surge cap.
• It can throttle legitimate incident traffic. A real outage that produces ten thousand errors in five minutes looks identical to a buggy deploy until you read the events.

The PAYG cap is the slider in billing settings. It is the hard ceiling. Setting it to zero means Sentry drops events the instant the included quota is gone. That is also the worst possible behavior during a real incident, because the events you most need to see are the ones that get dropped. Most teams set a non-zero cap that covers a typical bad month and call it insurance.

The cap is a per-billing-period number, not per-hour. A flood that consumes the whole month's PAYG budget in eight minutes leaves you with no overage capacity for the rest of the cycle. If the next incident lands on the 18th, the events get dropped.

The four levers that move the bill at flood time

Once the deploy is out and the flood is in flight, you have four places to pull. Three are configured in advance; one is a billing setting.

1. Span sampling at the SDK. tracesSampleRate (or traces_sample_rate) thins the span line item proportionally. A flood at 0.1 sampling sends one in ten transactions, with all spans inside. This is the safest sampling to reduce; the loss is observability detail, not incident visibility.
2. Replay sampling on errors. replaysOnErrorSampleRate is the single most expensive default in a typical setup. Set it to 0.05 or 0.10 unless replays are actively used in triage. The first incident where a $300 replay bill arrives is the one that resets this knob organization-wide.
3. before_send and beforeSendTransaction filters. These run inside the SDK and can drop events conditionally. The classic flood defense is a before_send that drops events when the exception fingerprint matches a known high-frequency pattern. The defense has to ship before the bug it is defending against.
4. Organization-level rate limits at the project. Configured under project settings, per-project rate limits cap ingest at a per-minute count regardless of plan quota. They are blunter than Spike Protection (no baseline learning) but they take effect immediately. Sentry's docs at docs.sentry.io/pricing/quotas/ walk the four quota layers.

The lever that does not exist: there is no SDK-side toggle that says "drop replays during a flood but capture them normally otherwise." The on-error sampling rate is a static configuration value. If you want adaptive replay sampling, you build it yourself in beforeSend.

What self-hosting changes about flood economics

The arithmetic above all has a per-unit price in it. Strip the price and the math collapses. A self-hosted Sentry-compatible backend has no per-event line item; it has a server bill that arrives whether the box did 200 events that day or 200,000.

Three differences in how a flood actually behaves on a self-hosted binary:

• The risk shifts from cost to capacity. The question stops being "how much will the bill be" and becomes "will the box stay up." That is a different defense pattern. The rate-limits and quotas guide walks the four layers that absorb the burst before it reaches storage.
• Sampling is a capacity decision, not a billing one. The 0.1 trace sample rate that exists to control the Sentry span bill becomes optional on a self-hosted backend. The reason to thin spans is "the storage tier is at 80% capacity," not "the PAYG budget is at 80%."
• Replays are still expensive on disk. Self-hosting removes the per-session price but not the per-session disk cost. A 1.0 on-error replay sample on a service that throws 100,000 errors a month still produces 100,000 replay payloads. The bill goes from "Sentry invoice line item" to "S3 bucket size," and the math is friendlier in the second column but it is still math.

urgentry today is a single Go binary against SQLite. The marginal cost of the Scenario C webhook flood on a $5 VPS running urgentry is the disk write time for 960,000 SQLite rows. The same flood on Sentry SaaS Team plan is $532. The two columns are not strictly comparable - one of them includes session replay capture that the other does not yet ship - but the cost shape is the headline.

For the same reason, the hidden cost of self-hosted Sentry piece is worth reading next: the ops time the binary saves you on flood nights has to be weighed against the ops time it costs you on every other night.

Frequently asked questions