A deployment guardrail is a rule that watches a metric during a rollout and aborts it automatically if that metric crosses a threshold. No one has to be staring at a dashboard when the regression happens, and rollback doesn't wait for a human to notice, page someone, and pull the trigger manually.
The three parts of a guardrail
Every guardrail is the same shape regardless of what it's watching: a metric (its values reach rollfuse as observations, sent through the API or pulled by a connector from an HTTPS source such as Prometheus's query API; see how to monitor a progressive rollout for the Prometheus wiring specifically), a threshold and comparison that says when the metric is in breach (p95 latency above 400ms, error rate above 1%, a business metric below a floor), and an evaluation window (the stretch of recent observations averaged on every check, so a single noisy data point is diluted instead of tripping the rollback on its own).
When the window's average crosses the threshold, the guardrail aborts the rollout: the flag goes back to serving its default variation to 100% of the environment, and the rollout stops advancing to its next stage. That's the entire mechanism: the complexity that matters is in choosing the right metric and threshold, not in the abort logic itself.
Reusable, not one-off
A guardrail policy is defined once as a template and attached to any rollout that needs it, rather than hand-written per rollout. That's what turns "someone remembered to configure the p95 guardrail correctly" into "every rollout installs the same reviewed p95 guardrail in one step." Installing a template is still an explicit action on each rollout; rollfuse doesn't attach it on its own. Guardrail Templates covers defining a threshold once and reusing it across every rollout that needs it.
What "automatic" actually prevents
The failure mode a guardrail exists to close isn't "nobody was watching" in the literal sense; most teams do watch major rollouts. It's the gap between a regression happening and a human deciding to act on it: the time someone spends noticing an alert, contextualizing it against a rollout in progress, and deciding rollback is the right call, all while traffic keeps advancing to the next stage. How Often Should a Guardrail Auto-Abort a Rollout? covers how to read your own abort rate and calibrate a threshold that closes that gap without firing on noise.
Guardrails don't replace judgment about which metric to trust
A guardrail is only as good as the metric it watches. A metric aggregated across an entire fleet, diluted by traffic still on the old version, can hide a stage-level regression a correctly-scoped metric would catch immediately, and a metric that looks fine at p95 can still be masking a real p99 problem underneath it. Anatomy of a Guardrail Near-Miss: When p95 Hides a p99 Problem is a concrete case where exactly that happened, and what changed afterward.
Attaching one
POST /v1/rollouts/{rollout_id}/guardrails
{
"metric_definition_id": "<p95 latency metric definition id>",
"comparison_operator": "gt",
"threshold": 0.4,
"evaluation_window_seconds": 300
}
This guardrail breaches when the average of the p95 latency observations (in seconds) over the last 300 seconds goes above 0.4. The values themselves reach rollfuse as observations, as described above. The guardrail is evaluated periodically for as long as the rollout is active or paused, not once per stage. See Driving a Progressive Rollout From a Go Service for it wired into an actual deploy.