How Epure keeps one looping error from flooding your inbox
Error tracking that isolates error floods: Epure stores a sample of each looping error, counts every occurrence, and keeps the next new bug visible.
On this pageShowHide
Store every event
- Payloads stored
- All of them
- Occurrences counted
- All of them
- What you give up
- One loop can spend the monthly quota
SDK sampleRate set to 0.1
- Payloads stored
- 10% of every error, rare ones included
- Occurrences counted
- Only the 10% that were sent
- What you give up
- Rare errors can be dropped before they arrive
Epure spike valve
- Payloads stored
- Up to 100 a minute per identical error, 150 per throw site
- Occurrences counted
- All of them
- What you give up
- Payloads past the budget; only the count remains
| Dimension | Payloads stored | Occurrences counted | What you give up |
|---|---|---|---|
| Store every event | All of them | All of them | One loop can spend the monthly quota |
| SDK sampleRate set to 0.1 | 10% of every error, rare ones included | Only the 10% that were sent | Rare errors can be dropped before they arrive |
| Epure spike valve | Up to 100 a minute per identical error, 150 per throw site | All of them | Payloads past the budget; only the count remains |
Rates from crates/server/src/pipeline/spike.rs in Epure v0.2.0. The same on Cloud Pro, Cloud Scale and self-hosted.
A retry loop throws the same TypeError on every request after a deploy. Ten minutes later the issue has thousands of events, the quota bar has moved, and a new checkout error is somewhere underneath. The fix for the loop is in your code. The job of the error tracker is to keep the inbox readable while you write it.
How does Epure isolate an error flood?
Epure gives every fingerprint its own budget. Each identical error may store 100 full events per minute, and each throw site may store 150 variants per minute. When a budget is empty, the event takes the counter-only path: the issue count goes up, but the payload is not written. The budget refills continuously, so a loop that slows down is sampled again on its own.
The budgets are token buckets in spike.rs. A throw site is the place in your code that raised the error; its budget catches a loop whose message changes on every call, such as an error that includes a request ID. Duplicate SDK retries of the same event are dropped separately, for 7 days, so a flaky network does not inflate the count.
What happens to the events past the spike valve limit?
Epure counts events past the spike valve limit without storing them. The issue keeps an exact occurrence count, so a loop that fires 40,000 times reads as 40,000 on one row, with a stored sample of full events to inspect. What you lose is the payload of each repeat. For a loop, those payloads are near copies of the stored ones: same stack, same message, different timestamp.
Choose a tool that stores every payload if your workflow needs each raw event, for example to audit every failed request by user. Epure keeps the count and a sample, which is what a two-person team reads during a flood.
Does an error flood hide new errors in Epure?
No. A different error has a different fingerprint, so its budget is untouched by the loop. The new error is stored with its stack trace and opens a new issue, and Epure's alerts on new, regressed and spiking issues fire for it. The looping issue can raise a velocity-spike alert of its own. Alerts follow issues, not events, so the channel never gets one message per occurrence.
Does the spike valve change my Epure bill or quota?
The spike valve never adds a charge. Epure Cloud has no automatic overage on any plan, and the valve uses the same 100 and 150 per-minute rates on Pro at $29, Scale at $89 and self-hosted. If a month still runs past its event quota, the over-quota rule applies: every occurrence is still counted, and new or regressed issues are still stored within a 5% grace.
What does the Epure spike valve not do?
- It does not fix the loop or slow your app down; the SDK still sends every event over the network.
- It does not store every payload past the budget; only the count remains for those events.
- It does not vary by plan: Pro, Scale and self-hosted use the same rates.
- It does not cover traces, replays or logs; Epure drops those at ingest.
How do I test the spike valve before production?
Test the Epure spike valve on staging before it matters. Point a staging build at an Epure project, throw the same error 500 times in a loop, then throw one different error. Expect two issues: the loop with a count of 500 and a stored sample, and the new error with its full stack. To estimate a month first, run the error storm simulator; it is a labelled simulation, not a load test.
If one error is already flooding Sentry today, start with how to stop an error loop in Sentry. When you are ready to compare plans, the Epure pricing page lists every limit.