"Feature flags" gets used to describe two genuinely different categories of tooling, and the difference matters more once a team is shipping continuously than it does at first glance.
Category one: on/off flags with targeting
The first category, general-purpose feature-flag tooling, solves a real problem: decoupling deploy from release. A flag lets code ship dark, then get turned on for a specific segment (internal users, a beta cohort, a percentage split) without a redeploy. Most of these tools do targeting well: rule-based segments, percentage rollouts, kill switches.
What they typically don't do is watch anything after the flag flips. The percentage split is a static configuration a human sets and later changes. It doesn't observe a metric and react.
Category two: guardrail-driven rollouts
The second category treats a rollout as a process with a policy attached, not a static toggle. A rollout advances through exposure stages on a schedule, and a guardrail evaluates a real metric, latency, error rate, a business metric, at each stage. A breach doesn't get emailed to someone to act on later; it aborts the rollout automatically, and the flag goes back to serving its default variation to 100% of the environment.
This is the category rollfuse is built for: staged rollouts with guardrails and automatic rollback as the default behavior, not an add-on bolted onto a flag system that was designed for targeting alone.
Where the line actually falls
The two categories aren't ranked. A kill switch or a simple beta-cohort flag doesn't need a guardrail attached, and adding one would be overhead without benefit. The line falls at risk: any release where a regression reaching 100% of traffic would be costly enough to justify automated detection and rollback is a release that benefits from the second category. A release where "someone notices and turns it off" is an acceptable failure mode doesn't.
In practice, most teams start with category-one tooling (it's simpler, and often what they already have), and hit the line later, usually after a release that reached full traffic before anyone noticed something was wrong, and the fix was a scramble instead of an automatic revert.
What to actually check when evaluating either category
- Does the tool evaluate a real metric against a threshold, or only let you configure a static percentage?
- If a threshold breaches, does anything happen automatically, or does it require a human to see an alert and act?
- Is the rollback a revert of the traffic split, or a full redeploy?
Those three questions separate the two categories more reliably than any vendor's own marketing does.