Why your Sentry bill exploded after a bad deploy

It's 2:14 AM. PagerDuty is screaming. The deploy that went out at midnight has a busted retry loop, and your frontend is throwing the same TypeError at every user on the site, four times a second, until they refresh.

You roll back. The errors stop. You go back to bed. Six days later, the bill arrives. The 90 minutes of broken-loop traffic ate two months of your error quota in a single sitting, and Sentry just upgraded you to the next tier — automatically, per the contract.

This is the per-event pricing trap, and it's the most common reason engineering teams come to us asking for a flat-rate alternative.

Why per-event pricing punishes the wrong moment

Per-event pricing assumes that error volume is roughly proportional to product usage. In a steady state that's mostly true. But error volume isn't bounded by traffic — it's bounded by the worst retry loop you accidentally shipped.

A single bad deploy can multiply your event volume by 50–100× while affecting the same number of users. The pricing model treats those events as identical to your normal background error rate, even though they all collapse to one bug, one fingerprint, one fix.

You don't pay more because you have more bugs. You pay more because you had one bug in the wrong place.

The two real costs

There are two costs that hit at the same time, and both are bad:

• The bill. Most per-event vendors auto-upgrade you to the next tier as soon as you cross the threshold. The new tier is annual. You just bought twelve months of capacity to absorb ninety minutes of regression.
• The reflex. The next time errors spike, your team will hesitate before keeping the SDK enabled, or will quietly raise sample rates, or will add filters that quietly drop the events that would have explained the next outage. Every per-event vendor eventually trains its customers to log less.

Patches that don't actually fix it

The standard advice from per-event vendors is some combination of:

• Sampling at the SDK
• Spike protection / event quotas
• Inbound filters and rate limits
• “Just call support and we'll credit you, this once”

Each one trades observability for predictability. Sample rates mean the one event you needed to debug the issue is the one that got dropped. Spike protection means your alert fires after the protection has already truncated the data. Goodwill credits assume you're willing to call support every time something goes wrong.

What flat-rate changes

Flat-rate pricing decouples the bill from the failure mode. The outage still costs you sleep, but it doesn't cost you anything extra on the invoice. Which means:

• You can keep the SDK at 1.0 sample rate in production without filing a budget request.
• Your on-call rotation isn't incentivized to silence noisy events — the noisy events are the ones that explain the next incident.
• Bad deploys cost you a postmortem, not a tier upgrade.

The math, without spin

Flat-rate isn't free, and it isn't cheaper for everyone. Below ~50,000 events per month, per-event pricing is genuinely the better deal. Between 50K and 500K, it's a wash on a normal month and a disaster on a bad one. Above 500K, flat-rate wins on a normal month and wins by an order of magnitude on a bad one.

Most teams cross that 500K threshold within their first year of meaningful traffic, usually without noticing — and then discover the threshold the same way our customers did: at 2 AM, looking at the dashboard, watching the counter spin.

The takeaway

Per-event pricing is a fine model for a tool you reach for occasionally. It's a bad model for a tool that runs in your production critical path and bills you more during the moments you're relying on it most.

If you've ever paged your finance team after an incident — or worse, sampled down your SDK to avoid having to — there's a better-shaped product for that job.