"Feature flags with Prometheus" usually means one specific thing in practice: using a metric that already lives in Prometheus to decide whether a flag's rollout should keep advancing, pause, or revert. It's worth being precise about that, because a feature-flag platform and a metrics database are two different systems doing two different jobs. Connecting them is a deliberate integration, not a built-in mode either one ships with by default.
What each side actually does
A feature-flag platform's job is targeting and exposure: who sees which variation, at what percentage, staged how. Prometheus's job is metric storage and query: what happened, aggregated and queryable via PromQL. Neither one is built to do the other's job. A feature-flag platform that claims to "support Prometheus" usually means one of two things: it can push its own operational metrics into Prometheus (useful for observability, irrelevant to rollout decisions), or it has some mechanism for a Prometheus-derived value to drive a rollout decision, which is the much rarer and more useful capability.
What that connection looks like concretely
rollfuse doesn't scrape Prometheus directly, being direct about that up front. What it does have is a guardrail model where a metric definition's value, however it got there, can automatically abort a rollout when it breaches a threshold. Getting a PromQL result into that pipeline is two API calls' worth of integration, not a platform feature to enable:
- Define the metric definition rollfuse should evaluate.
- Get the PromQL result into it, either pushed on a schedule matching your evaluation window, or pulled via a Connector configured against Prometheus's own query API.
Once that's wired, the flag's staged rollout behaves exactly like any other guardrail-backed rollout: the Prometheus-derived value is evaluated on schedule, and a breach reverts the flag's exposure automatically.
The honest version of "supports Prometheus"
If a platform's Prometheus story is "you can point a generic webhook or API at it," that's a real, useful capability. It's just not the same claim as "we speak PromQL natively" or "connect your Prometheus in one click." Worth checking which one you're actually being sold before you design a rollout process around it. The gap between the two isn't usually large in effort (a small script or a mapped Connector), but it's real, and skipping past it in the planning stage is how a team ends up with a guardrail that was supposed to be watching a metric that never actually arrived.