Guides and playbooks
Progressive Rollouts Readiness Checklist
Pre-rollout checklist covering flag setup, monitoring, rollback planning, and team communication — verify every prerequisite before starting a Progressive Rollout.
Run through this checklist before activating a Progressive Rollout. Each item is a prerequisite — if any box is unchecked, resolve it before you begin.
Flag setup
- Flag is created and published in the target environment.
- Target values are configured — the rollout value (new behavior) and the default value (current safe behavior) are both defined.
- Targeting rules are in place if the rollout should be scoped to a specific segment, attribute, or context.
- Application code supplies an inline default that matches current safe behavior, so users outside the rollout are unaffected during network interruptions or cache misses.
-
SDK is initialized with the correct environment key (
ZENMANAGE_SERVER_KEYorVITE_ZENMANAGE_CLIENT_KEY). - Initial rollout percentage and mode (Manual or Automatic) are decided.
Monitoring
- Error tracking is active and alerting on the affected service or code path.
- Performance baselines (p95/p99 latency, throughput) are captured so you have something to compare against during the rollout.
- Business metric dashboards (conversion, activation, or transaction events) are accessible if the rollout touches a user journey.
- Support ticket and in-app feedback channels are being monitored for unexpected volume.
Rollback plan
- Team understands the Pause action — pausing stops the rollout and serves the pre-rollout fallback value to everyone; the rollout percentage is preserved so you can resume later.
- Team understands the Remove path — removing the rollout configuration reverts all users to the flag's published default, fully ending rollout exposure.
- Kill-switch procedure is documented for emergencies that require immediate mitigation beyond pausing (see Kill Switch and Incident Rollback guide).
- Criteria for pausing vs. rolling back are agreed upon (metric thresholds, error rate limits, or qualitative signals).
Communication
- Team members who need to know about the rollout have been notified (engineering, product, support).
- On-call coverage is confirmed for the duration of at least the first rollout stage.
- Escalation path is documented — who to contact and how if the rollout needs an urgent pause or rollback outside normal hours.
- Rollout timing avoids known risky windows (deployments, maintenance, low-coverage periods).
Related resources
- Progressive Rollouts Playbook — step-by-step guide to configure, monitor, expand, and complete a rollout.
- Progressive Rollouts — capability overview covering Manual and Automatic modes, deterministic bucketing, and scheduling.
- Canary Release Playbook — step-by-step canary workflow with go/no-go decision criteria, recommended percentages, and monitoring duration.
- Kill Switch and Incident Rollback — the fastest path from incident detection to mitigation without a redeploy.
- Governance Checklist — naming, ownership, and lifecycle hygiene for flags before and after rollouts.
- Launch Readiness Checklist — end-to-end checklist covering feature completeness, documentation, support, and post-launch monitoring.
Ready to run your first rollout? Start your free trial and create a flag in minutes.
Next step
Take the next integration step in your own stack.
Start with the quickstart that matches your runtime, then return to the reference pages when you need exact request and payload details.