App Ops Desk · Issue #16
Phased release is not a parachute
Phased release feels like insurance. Without a halt rule and a watch window, it is just slow exposure to the same bad build.
One action this week: Before your next phased release, write the halt criteria: crash free users, support volume, and payment errors that pause the rollout.
What phased release actually does
It gradually makes an update available to a percentage of automatic-update users. It does not replace TestFlight, archive smoke, or store-facts freeze.
Solo halt criteria
- Crash rate above your baseline for N hours
- Login / purchase failure spike
- Support inbox hits a written threshold
- A privacy/permission storm you did not expect
Failure modes
- Turning phased on and ignoring Connect for two days
- No baseline metrics, so every crash looks “maybe normal”
- Hotfix ready in git but no rollback note for testers still on old build
- Assuming manual adopters are covered by phased percentages
Watch window checklist
Phased day 0–1: [ ] Crash dashboard open [ ] Revenue / trial start sanity check [ ] Support label for this version [ ] Halt criteria written [ ] Hotfix branch ready if critical path fails
Bottom line
Phased release buys time to notice. It does not buy forgiveness. Write halt rules before you tap release.
Resources hub → Full library and jump-by-symptom links. Join the App Ops Desk waitlist Weekly release ops for people who ship alone.