Skip to content

Gradual Rollout

Pilot → 1% → 5% → 25% → 100%. Named exit criteria at each step. The dashboard tells the team whether to advance, hold, or revert.

Owners: PO, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: The check is observation — and observation at 1% is cheaper than observation at 100%.

Where it lives in the chain

How to do this

For every release behind a flag, the rollout plan names:

  1. Stages and audiences. "Pilot 5 schools → 1% all schools → 5% → 25% → 100%."
  2. Exit criteria per stage. "Advance to next when: error rate within SLO for 24h, adoption above 60% of available users, no P0/P1 bugs filed."
  3. Soak time per stage. "24 hours minimum at each percentage. Pilot stage 1 week."
  4. Watch dashboards. Named, owned, reviewed at each step. Same dashboards the first-48-hours discipline uses.
  5. The revert condition. "If any of: SLO breach >5 min, data integrity concern, P0 incident — flag off immediately, investigate in staging."

What good practice looks like

A team rolling out the grading shortcut:

StageAudienceSoakExit criteria
Pilot5 schools, opted in1 weekFive PO reads of the dashboard; one round of pilot feedback; zero P0/P1 bugs.
1%random sample24hAdoption ≥40%, error rate within SLO, no helpdesk pattern.
5%random sample24hSame metrics, broader sample.
25%random sample24hSame metrics; load profile matches expected.
100%allSoak for 2 weeks before flag removal; signal reading at +30 days.

The PO does not advance based on absence of bad news. Advance is an active decision, based on the dashboard. If nobody watched the dashboard, the answer is "we don't know yet" — and the stage holds.

The wallet bug surfaced at staging exploratory, before any rollout. The JWT outage bypassed gradual rollout entirely — deployed to all environments simultaneously. That bypass is the lesson: gradual rollout exists for exactly the changes the team is most sure of, because those are the changes that surprise.

200apps · How We Work · NWIRE