Spike valve: fingerprint floods without melting the box
Retry storm? Soft sample can return 202, bump counts, and drop excess bodies. Hard hourly cap returns 403. Defaults from docs.
On this pageShowHide
You notice Issues stuck on one fingerprint and the box fans spin. That is the spike valve job: keep triage usable without a SaaS overage invoice on self-host.
When a fingerprint floods
exception -> SDK -> DSN -> ingest -> fingerprint. Soft sample: 202 plus counter, drop excess bodies. Hard cap: 403 ingest_cap_exceeded.
Documented defaults
Cite docs only. Soft sample ~100 raw events/min/fingerprint. Hard cap default 5000/hour/project. Confirm current numbers in docs/api/errors before changing ops runbooks.
How to observe
- Send a repeated known exception fingerprint in a controlled test (staging).
- Watch HTTP status: 202 during soft sample; 403 after hard cap.
- Confirm issue counter behavior in the UI.
- Read app logs for drop/cap messages.
Related wire path: Envelope keep/drop.
Ops notes
- Soft sample is not unlimited ingest. Disk and Postgres still grow with retained events.
- Tuning belongs in documented env/config; do not invent keys here.
- Self-host: you own backups after floods (Backups).
Questions
Does 202 mean the body was stored?
Not always under soft sample. Counter can bump while excess bodies drop. Read docs for the exact contract.
Is this a Sentry PAYG replacement claim?
On self-host there is no Epure overage invoice. You still pay the VPS and own the ops. SaaS Sentry meters are a different invoice shape (vs Sentry).
Redis required?
No. In-process on the Rust binary.
Cloud soft-sample?
Published Cloud plans describe soft-sample; Cloud is not live yet.