Rollout percentages are usually a guess
Choosing 5%, 10%, or 25% as a feature flag rollout percentage typically comes down to a rough sense of "cautious enough" rather than an actual calculation. This works fine when nothing goes wrong, and produces genuinely surprising numbers when something does — a percentage that felt appropriately small in the abstract can represent tens of thousands of real users once multiplied against an actual user base.
The calculation that turns a percentage into a real number
The first and most basic number worth calculating explicitly: total users multiplied by rollout percentage. A product with 500,000 active users at a "cautious" 10% rollout exposes 50,000 real people to whatever that flag does — a number that reads very differently than "10%" does on its own, and is worth seeing explicitly before committing to a rollout plan.
Why the detection window matters as much as the rollout percentage
A rollout doesn't stop exposing new sessions the instant a bug is detected — it continues exposing new users and sessions for however long it takes to notice the problem and execute a rollback. A realistic detection-and-rollback time (commonly ranging from a few minutes with strong monitoring to much longer without it) multiplied by your traffic rate during that window adds meaningfully to the total blast radius beyond the initial rollout snapshot.
Turning affected sessions into an actual cost estimate
Multiplying affected sessions by an average per-session value — whether that's average order value, subscription value, or another relevant metric for your product — converts an abstract user count into a concrete dollar figure that's far more useful for deciding how cautious a rollout percentage genuinely needs to be, and for communicating risk to stakeholders in terms that register.
Why a comparison table beats a single number
Seeing exposed users and estimated impact side by side across several rollout percentages — 1%, 5%, 10%, 25%, 50%, 100% — makes the actual tradeoff visible: how much validation on real traffic you gain at each step up, against how much additional exposure that step represents if something goes wrong. This tradeoff is much harder to reason about from a single number in isolation.
Why blast radius scales linearly, and why that's useful to know
Because exposure scales linearly with rollout percentage, halving an initial rollout roughly halves both the exposed user count and the estimated cost if something goes wrong — while still providing real production validation on actual traffic. This straightforward relationship makes it easy to reason about the tradeoff between validation speed and risk exposure at any point along the rollout curve.
Making rollout decisions with numbers instead of instinct
None of this replaces good engineering judgment about how confident a team is in a given change — but replacing a purely instinctive percentage choice with an explicit calculation of exposed users, affected users if something goes wrong, and estimated cost gives that judgment something concrete to work from, rather than relying entirely on a percentage that sounds appropriately cautious.
Frequently Asked Questions
10% is easy to perceive as a small, cautious number in the abstract, but multiplied against a real user base it can represent tens of thousands of actual people. A product with 500,000 active users at a 10% rollout exposes 50,000 real users — a number that reads very differently once calculated explicitly rather than left as a percentage.
A rollout continues exposing new users and sessions for however long it takes to detect a problem and execute a rollback — it doesn't stop the instant something goes wrong. This detection window, multiplied by your ongoing traffic rate, adds meaningfully to total exposure beyond the initial rollout snapshot.
By multiplying the number of sessions likely affected during the exposure and detection window by an average per-session value relevant to your product — average order value, subscription value, or a similar metric — turning an abstract affected-user count into a concrete cost figure.
Yes — exposure scales directly with rollout percentage, so halving an initial rollout roughly halves both the exposed user count and the estimated cost if something goes wrong, while still providing meaningful real-traffic validation of the change.
Yes — the Feature Flag Blast Radius Calculator takes your total users, rollout percentage, expected error rate, and detection time, and calculates exposed users, affected users if bugged, sessions exposed during detection, and estimated cost, plus a full comparison table across common rollout percentages.