Sentry quota exceeded: what happens to your errors

On the 19th of the month, Usage Stats show the error quota used up. The issue list looks calm, and that is the catch: from this point, a new error introduced by your next deploy leaves nothing to open until the usage period resets. The sections below follow Sentry's documented behaviour at the limit, then the settings that move it.

What happens when your Sentry quota is exceeded?

When a Sentry organization exceeds its quota, Sentry stops accepting events in that category until the next usage period starts. The quota docs say events and attachments over quota are not accepted. The help article on exhausted quota adds that dropped events can't be queued or recovered, even after the quota goes up (both checked 6 Nov 2026). On Team, the error quota is the 50,000 included errors plus any reserved volume and pay-as-you-go budget.

Counting stops with it. A dropped event does not raise the count of its issue, so a known error that keeps firing reads as stable, and a new error leaves no issue at all. The free Developer plan includes 5,000 errors a month and has no pay-as-you-go, so an upgrade is the only way back before the reset.

What does the Sentry SDK receive when the quota is exceeded?

The Sentry SDK learns about quota and rate limits from the server's response: an HTTP 429 with a Retry-After header, or an X-Sentry-Rate-Limits header that names the data categories and the seconds until the limit expires. Sentry's SDK rate-limiting spec requires SDKs to stop sending those categories and to discard the affected payloads while the limit lasts, without queueing them. A 429 that carries neither header makes the SDK assume a 60-second limit for every category (checked 6 Nov 2026).

Nothing fails loudly: the SDK drops the event locally by design, and your application keeps running. To see the effect, open Stats > Usage Stats in Sentry, which shows accepted, dropped and filtered events per project for up to 90 days.

When does the Sentry quota reset?

A Sentry quota resets at the start of the next usage period, and new events are refused until then. Unused reserved volume expires at the end of each billing month and does not roll over, according to Sentry's pricing docs (checked 6 Nov 2026). A flood on day 3 can therefore leave the rest of the month uncovered, while a quiet month leaves reserved volume you paid for unused. Raising the quota mid-month only helps events that arrive after the change.

How does Sentry's pay-as-you-go budget change what happens?

Sentry's pay-as-you-go budget pays for volume past your reserved quota, so events keep arriving until the budget is spent, and then they drop. The budget is shared across all data categories on a first-come, first-served basis, so spans or replays can spend it before an error flood needs it (pricing docs, checked 6 Nov 2026). On Team, errors past the 50,000 included cost $0.0003625 each up to 100,000, then $0.0002188 each up to 500,000.

Team and Business also include spend notifications and a maximum spend threshold (sentry.io/pricing). Set both before a flood, so the budget is a decision you made rather than a number you discover.

Does Sentry spike protection save your quota?

Sentry's spike protection saves quota by dropping events above a per-project threshold while a spike lasts, and dropped events are not charged. The threshold comes from a weighted average of the last 168 hours of usage and is recalculated every hour during the spike (spike protection docs, checked 6 Nov 2026). A Manager, Billing or Owner member turns it on per project, notifications need a separate action, and the feature does not apply during trials.

The trade-off is where the threshold sits. It is set per project, not per issue, and the docs describe no exemption for other issues, so a new bug that starts during a flood competes with the flood for the same allowance. If high volume persists, the docs add, it becomes the new baseline, and the quota can still run out. For the flood itself, stopping the error loop at its source works better than any threshold.

What do you stop seeing when the Sentry quota runs out?

When the Sentry quota runs out, you lose every signal that depends on an accepted event. A new bug introduced by the next deploy creates no issue, so no new-issue alert can fire. Counts on existing issues stop growing, so a worsening error reads as flat. For one or two developers shipping several times a day, a 10-day gap before the reset covers every deploy in those ten days.

• New issues: no first event arrives, so there is no issue and no stack trace to open.
• Regressions: a resolved issue that comes back stays resolved, because its events are dropped.
• Counts: occurrences after the limit are missing from every issue, so the issue list understates the problem.

How do you avoid exceeding the Sentry quota?

Two common causes of a Sentry quota running out early are one error repeating thousands of times and tracing left on at a high tracesSampleRate. Spans have their own allowance, 5,000,000 a month on Team, but they share the pay-as-you-go budget with errors, so heavy tracing can spend the money that would have kept errors flowing. Find the category in Stats > Usage Stats first, then fix the cause, because a bigger budget only moves the day the quota runs out.

• One looping error: fix it and filter only that event. The guide to stopping an error loop covers beforeSend, ignoreErrors, inbound filters and rate limits.
• Tracing you don't read: set tracesSampleRate to 0 and keep errors, as shown in turning off Sentry tracing.
• Budget controls: turn on spend notifications and set a maximum spend threshold on Team or Business.
• A bill that already rose: find the meter that moved before cutting data.

What does Epure do when you exceed the quota?

Epure Cloud keeps counting past the monthly quota and keeps the first event of each new or regressed issue, so new problems still show up with a stack trace. That grace is 5% of the quota: on Pro, 10,000 first events past the 200,000 included; on Scale, 75,000 past 1,500,000. Repeat payloads of existing issues are not stored, but every occurrence is counted. Epure emails at 80% and 100% of the quota and suggests the next plan. The rule shipped in v0.2.0 on 5 Nov 2026.

Past the grace, existing issues are still counted, and only new fingerprints are refused until the next month or a plan change. There is no automatic overage and no auto-upgrade, and self-hosted Epure is never limited. Epure pricing states the rule in full.

Below the quota, the spike valve stores at most 100 identical events a minute per error and counts the rest. A loop therefore uses quota more slowly, though it can still reach it: at that ceiling, one loop running nonstop would reach Pro's 200,000 no sooner than about 33 hours. Fixing the loop still matters on Epure, and the over-quota rule is what keeps new issues visible if you can't fix it in time.

Sentry covers more ground. Its spike protection also handles spans and attachments, Team keeps up to 90 days of lookback against 30 days on Epure Pro, and the Developer plan is free with 5,000 errors a month. Epure tracks errors only and is in Beta. There is no free Cloud tier: Cloud starts with a 14-day trial without a card, and self-hosting is free.