Progressive rollout, advancing a release through increasing traffic percentages, each stage gated on the last one being healthy, is only as good as what's deciding "healthy." For most teams, the data that would answer that question already lives in Prometheus: request rate, error rate, latency histograms, all queryable via PromQL. The gap is usually not the data. It's connecting that data to the thing that actually advances or halts the rollout.
What Prometheus gives you, and what it doesn't
Prometheus and Alertmanager can tell you a query result crossed a threshold, and page someone about it. Neither one advances a rollout stage, holds it, or reverts it. That decision has to live somewhere else, evaluated against the rollout's own state (which stage is active, how long it's been there) as well as the metric.
To be specific about rollfuse here: there's no built-in Prometheus scraper. What exists is a rollout with staged, scheduled percentage targets, and a guardrail attached to it that evaluates a metric definition on a schedule. The metric's value has to get to rollfuse somehow, and Prometheus isn't the thing that puts it there on its own.
Two ways to close the gap
Push it. Compute the PromQL result on whatever cadence matches your guardrail's evaluation window, and push it as an observation:
POST /v1/environments/{environment_id}/metric-definitions/{metric_definition_id}/observations
{
"value": 0.987,
"observed_at": "2026-08-27T09:15:00Z"
}
Pull it. A Connector, configured with a contract template that maps Prometheus's HTTP query API response to {value, observed_at}, polls it on a schedule without you hosting a script yourself.
Either way, once the value lands as an observation against the right metric definition, it behaves identically to any other guardrail metric: evaluated continuously against the rollout's threshold, with a breach reverting the rollout's traffic percentage automatically.
Why "progressive" and "automatic" have to go together
A progressive rollout with no automated gate is really just a slow full rollout. The staging buys you nothing if every stage advances on a timer regardless of what the metrics say. The entire value of staging traffic is contingent on something actually checking, at every stage, whether it's safe to continue. If Prometheus already has the signal, the missing piece usually isn't more instrumentation. It's the one API call that lets that signal actually stop the rollout instead of just recording that it should have.