Workflow: quota governance that keeps spend predictable

# Workflow: quota governance that keeps spend predictable

Sentry bills by data category, and each category has its own quota. Governance means budgets per category, per project, reviewed monthly.

## 1. Learn the categories

Errors, transactions, replays, spans, profiles, and cron check-ins each draw from their own quota. A spike in one never borrows from another, which is good for isolation and bad if you only watch the total.

## 2. Set budgets per project

For each project, decide what each category should cost:

- Errors: full fidelity, always. This is the product's core job.
- Traces: sampled by route value (see the sampling workflow). A flat 1.0 on a hot service is the classic budget fire.
- Replays: session rate low, error rate high.
- Spans/profiles: fractions of the trace rate.

## 3. Enable spike protection

Spike protection is configured per project and drops excess volume when a category spikes. It is the circuit breaker that turns a runaway deploy into a quota event instead of a bill event. Enable it everywhere before you need it.

## 4. Tune rates before raising quotas

When a project nears its budget, the first move is sampling tuning, not a quota increase. Check which routes or SDK options generate the volume; a noisy health-check route is a config fix, not a spending decision.

## 5. Monthly review loop

- Usage stats per project per category: trending up, flat, or spiky.
- Spike protection events: each one is a deploy or config worth understanding.
- New projects: every new service gets budgets and spike protection on day one, not after the first surprise bill.

## Verify

Simulate a spike in staging (temporarily raise a sample rate) and confirm spike protection engages and the alert reaches the team. A governance system you have never seen fire is a hope, not a system.