Diagnose: quota exhausted mid-month

# Diagnose: quota exhausted mid-month

## Step 1: find the burner

Open the Usage tab of Stats (any org member can view it) and break down by project and data category. One project and one category almost always dominate. Billing members can download the full project breakdown from Settings > Subscription.

## Step 2: classify it

- **Genuine growth:** traffic grew, per-event volume is sane. The quota is undersized; raise it.
- **A spike:** a deploy, retry storm, or upstream outage multiplied volume 10x. Spike protection should have caught it; if it was off, that is the lesson.
- **Chronic noise:** the same few issues or transactions burning quota every day. This is a config problem, not a quota problem.

## Step 3: cut at the source, cheapest first

The docs order these easiest-first, and it is the right order:

1. Enable spike protection per project (Settings > Spike Protection).
2. Fix the bug or the retry storm causing the spike.
3. Lower `tracesSampleRate` / `traces_sample_rate`; add `ignoreErrors` and `beforeSend` filters for the chronic noise.
4. Rate-limit attachments (they are shockingly large per event).
5. Only then adjust the quota or add pay-as-you-go.

Raising quota before cutting the source just funds the noise.

## Step 4: prevent recurrence

Set a quota-usage alert so the next spike pages someone before the month is gone. Review the Usage tab weekly for the first month after any sampling change.

## Verify

Watch the category's usage curve fall back under the threshold line over the next days, and confirm 429s stop. If volume stays high with sane sampling, the traffic genuinely needs the bigger quota.