There is no universal "right" auto-abort rate for a guardrail, and rollfuse doesn't publish one. What you can do is read your own abort rate correctly. A rate of zero is the number that deserves the most suspicion, because a guardrail that never fires may simply be set too loose to catch anything.
What a guardrail does in rollfuse
A guardrail attaches a threshold on one metric to a rollout, with a comparison (greater than, less than, or the "or equal" variants) and an evaluation window. While the rollout is active, rollfuse periodically compares the average of that metric's observations inside the window against the threshold.
If the threshold is breached, the rollout is aborted through the same path a manual abort uses: the flag goes back to serving its default variation to everyone in that environment. Every evaluation is recorded with the metric value, the threshold and the action taken, so each abort leaves a record of why it happened. A window with no observations is recorded as insufficient data and never aborts a rollout by itself.
Why zero aborts is a warning sign
A guardrail that never fires isn't conservative. It's decorative. If your abort rate sits at zero for months, either every release your team ships is flawless, or the threshold is so loose that a regression is already visible to every user before the guardrail would react.
The second case can happen when a threshold is copied from an old alert that was tuned to avoid paging people, not to stop a rollout at 5% of traffic. An alert threshold answers "is this bad enough to wake someone up?". A rollout guardrail should answer "is this release worse than what it replaces?", which is a tighter question.
Calibrating without crying wolf
The failure mode on the other side is just as real: a guardrail so twitchy that it aborts healthy rollouts on ordinary noise, until the team stops trusting it.
A few habits help:
- Set the threshold from the service's own recent behavior. A naturally noisy service needs more headroom than a stable one. The threshold in rollfuse is a fixed number you choose, so look at the metric's normal range before you pick it.
- Use the evaluation window to absorb noise. A longer window averages more observations, so a single slow request is less likely to trip the guardrail. A shorter one reacts faster. Choose per metric.
- Treat a false positive as a calibration bug. When a guardrail aborts a rollout that turns out to be fine, look at the recorded value and threshold for that evaluation and adjust. Don't accept false aborts as the price of safety.
Reading your own abort rate: a hypothetical example
Hypothetical example: this scenario is invented to show the method. It does not describe a rollfuse customer, an internal measurement or a real incident.
Imagine a team that protects its checkout releases with a p95 latency guardrail and an error-rate guardrail. After a quarter, they list every auto-abort and sort each one into one of three groups:
- Caught early. A real regression that would have spread to more traffic before anyone noticed: a slow memory leak, a cache-miss cascade, a dependency timeout that only appears under real load.
- Caught faster. A real problem that the on-call engineer would also have caught, just later, after more users saw it.
- False positive. The release was fine and the guardrail reacted to noise.
How the list splits tells the team what to do. Mostly groups 1 and 2 means the guardrails are doing their job. A growing group 3 means a threshold or window needs adjusting. An empty list after many releases is the case to look at first: check whether the threshold could ever be reached at the traffic levels of the early stages.
Where to go from here
Guardrail templates let you define a calibrated threshold once and reuse it, so a fix to one threshold doesn't have to be repeated on every rollout. Deployment guardrails covers the broader idea of automatic checks during a release, and the automatic guardrail rollback tutorial walks through setting one up.