You already have the metric. http_requests_total with a status label, a p99 latency histogram, a queue-depth gauge, whatever your services already expose to Prometheus. The gap most teams have isn't visibility. It's the last step: turning a metric breach into an actual rollback, without someone watching a dashboard and reacting by hand.
A rollfuse guardrail does that step. It doesn't query Prometheus by itself: the value has to reach rollfuse as observations, either pulled by a connector or pushed by a job of yours. Once the observations are there, a rollout whose metric crosses the threshold is aborted automatically.
1. Define the metric in rollfuse
A metric definition names the metric and its unit. It holds no PromQL; the query stays in your Prometheus.
POST /v1/projects/{project_id}/metric-definitions
{
"name": "Checkout 5xx ratio",
"key": "checkout_5xx_ratio",
"aggregation_type": "average",
"unit": "ratio"
}
2. Get the Prometheus value into rollfuse
Pull it with a connector. A connector calls an HTTPS URL periodically (and whenever you trigger a sync), sends its pull secret as Authorization: Bearer <secret>, and turns the JSON response into observations using an approved contract template. Prometheus's instant-query endpoint can be that URL, for example https://prometheus.example.com/api/v1/query?query=<your PromQL, URL-encoded>. Its response keeps each series under data.result, with the point as a [timestamp, "value"] pair, so the mapping is:
{
"root_path": "data.result",
"value_field": "value.1",
"observed_at_field": "value.0",
"observed_at_format": "unix_seconds"
}
You can test a mapping against the live URL before saving anything, and the connectors tutorial walks through preview, creation and sync. The URL must be HTTPS and reachable from rollfuse, and whatever answers it (Prometheus or a proxy in front of it) must accept or ignore the bearer header.
Push it from your side. A job you run executes the PromQL query and sends the result with a service credential that has the metrics:write scope:
POST /v1/environments/{environment_id}/metric-definitions/{metric_definition_id}/observations
{
"observations": [
{ "value": 0.004, "occurred_at": "2026-10-11T14:00:00Z" }
]
}
3. Attach a guardrail to the rollout
A guardrail references the metric definition, a comparison operator, a threshold and an evaluation window. You can create it in the console or through the API:
POST /v1/rollouts/{rollout_id}/guardrails
{
"metric_definition_id": "<metric_definition_id>",
"comparison_operator": "gt",
"threshold": 0.01,
"evaluation_window_seconds": 900
}
The automatic rollback tutorial walks through this call and how to read the guardrail's evaluation history.
How the evaluation window works
On every evaluation, rollfuse averages the observations from the rollout's environment that fall inside the window ending at that moment, and compares the average with the threshold. A single spike gets diluted by the rest of the window instead of firing a rollback on its own. A window with no observations is recorded as insufficient data, not as a breach.
What "rollback" actually does
Reverting doesn't mean redeploying the previous build. When a guardrail breaches, rollfuse aborts the rollout: the flag goes back to serving its default variation to 100% of that environment, and the rollout stops advancing. Your SDKs pick up the new configuration on their next update. The regression is still deployed; it's just no longer served while someone investigates.
What gets recorded
Every evaluation is stored with the averaged value, the threshold, whether it breached and, on a breach, the action taken. You can browse that history per guardrail in the console, so "why did this roll back" has an answer in the record.
Limits worth knowing
- rollfuse has no built-in Prometheus scraper and doesn't run PromQL. Your Prometheus answers the query; rollfuse only sees the numbers that reach it.
- The guardrail reacts to the number you send. If the query measures the whole service, the guardrail reacts to the whole service, not only to the traffic in the rollout.
- A connector authenticates only with a bearer token over HTTPS, and a project can have up to 20 connectors.