Progressive Rollouts
Release to 1%.
Expand with data.
Halt in 0 seconds.
A progressive rollout is the safety net every feature launch needs. Instead of shipping to 100% of users and hoping for the best, Signal lets you expand your audience in stages — watching metrics at each step, ready to halt instantly if anything looks wrong.
The problem
Full-blast launches
hide problems
until it is too late.
When you ship to 100% of users at once, the blast radius of any bug is your entire user base. By the time your monitoring alerts, thousands of sessions may already be affected. A rollback means a redeploy — which takes minutes, during which the problem continues.
Progressive rollouts change the equation. At 1%, a bug affects 1% of users. Your monitoring catches it in seconds. You set the rollout to 0% — Signal pushes the halt instantly to every client via WebSocket — and the problem is over before most users ever noticed.
The four stages
A safe launch
in four steps.
1%
Canary
Internal team + opted-in testers
Confirm no catastrophic errors. Check error rates and performance metrics. Gather the first qualitative feedback.
Go signal: Error rate stable, p99 latency unchanged.
10%
Early adopters
First external cohort, typically paying users
Real-world load at meaningful scale. Watch support tickets, NPS, and conversion funnel for anomalies.
Go signal: Support ticket delta <= baseline. Conversion rate holds.
50%
Majority
Half your active user base
Statistical significance. A/B comparison between flag-on and flag-off cohorts is now meaningful.
Go signal: Metrics equal or better than control group.
100%
General availability
Everyone
Feature is live. Archive the flag, clean the dead code path, remove the conditional from your codebase.
Go signal: Stable for one sprint. Time to delete the flag.
Under the hood
Same user.
Always the same experience.
Signal uses deterministic hashing to assign users to a rollout bucket. Given the same user ID and flag key, the hash always produces the same value — so a user in the 10% cohort stays in the 10% cohort regardless of how many times they reload the page or how many SDK instances are running.
There is no session state, no cookie, no server-side sticky session to manage. The bucketing is pure math — fast, consistent, and impossible to game.
Bucketing formula
hash(userId + flagKey) % 100 < rolloutPctFAQ
Common questions.
- How does Signal decide which users get a flag at a given percentage?
- Signal uses a deterministic hash of the user ID (or a sticky session identifier you provide). For a 10% rollout, any user whose hash falls in the first decile receives the flag. The same user always gets the same value — no flickering between page loads or sessions.
- Can I combine a percentage rollout with a segment?
- Yes. A flag can target a specific segment first, then apply a percentage within that segment. For example: "10% of enterprise accounts" rolls out only among users matching the enterprise segment, not across your entire user base.
- What happens if I reduce the rollout percentage?
- Users whose hash no longer falls within the new threshold immediately receive the fallback value. The transition is instant — no cache to clear, no deploy to trigger.
- Is there an audit log of rollout percentage changes?
- Audit logging is on the roadmap and will be available before general release. During the private beta, flag change history is visible in the dashboard.
Join the waitlist
Ship your next feature
with confidence.
Join the waitlist. We will reach out personally before we open access.
No spam. One email when we open.