Release readiness
A practical checklist we walk before recommending expand, hold, or monitor on an iOS or Android train.
Before the expand call
What we verify on every assessment
Use this list internally, or bring it to a Release Health Assessment and we will fill the evidence column with you.
- Baseline locked. Prior stable build identified, with crash-free and ANR numbers at matching rollout depth.
- Candidate build identified. Store version, build number, and staged percentage documented for both platforms if dual-ship.
- Top crash clusters reviewed. New versus known signatures separated; user-facing journeys tagged.
- ANR / hang concentration checked. Device class and OS skew understood before blaming the binary alone.
- Cold-start sample at relevant hours. Especially for KR evening peaks when radio and CDN load differ from midday.
- Hold criteria written in plain language. Product and support can explain the hold without reading stack traces.
- Exit from hold defined. What evidence allows expand later — hotfix, longer window, or device-targeted pause.
- Support and store signals scanned. Review spikes and ticket themes tied to the release window, not only crash charts.
Intake
Credentials, baselines, and expand timetable collected. Gaps are listed before analysis starts.
Signal pass
Crash, ANR, startup, and store signals compared to the locked baseline for the candidate build.
Decision brief
Go / hold / monitor with thresholds and open uncertainties. Shared ahead of the live session.
Release meeting
Sixty minutes with release owners to align on the call and the exit criteria if holding.