Planner inputs
Enter production traffic, canary ramp settings, and guardrails. Submit to generate a step-by-step rollout plan with exports.
Example data table
Example schedule using 200,000 requests/hour, 50,000 users, 5% start, 10% increments, 2 hours per step, and a 50% max canary.
| Step | Traffic | Users | Duration | Estimated requests | Decision |
|---|---|---|---|---|---|
| 1 | 5% | 2,500 | 2h | 20,000 | Verify dashboards and alerting |
| 2 | 15% | 7,500 | 2h | 60,000 | Check error budget and p95 drift |
| 3 | 25% | 12,500 | 2h | 100,000 | Run smoke tests and canary comparisons |
| 4 | 35% | 17,500 | 2h | 140,000 | Validate scaling and queue depths |
| 5 | 45% | 22,500 | 2h | 180,000 | Confirm SLOs remain stable |
| 6 | 50% | 25,000 | 2h | 200,000 | Approve rollout or rollback |
Formula used
- Ramp schedule: traffic at step i is pᵢ = min(start + (i−1)×increment, max).
- Users exposed: usersᵢ = total_users × (pᵢ / 100).
- Estimated canary requests: reqᵢ = requests_per_hour × duration_hours × (pᵢ / 100).
- Rollback thresholds: error ≤ baseline + Δerror, and latency ≤ baseline × (1 + Δlat/100).
- Sample size (approx): normal approximation for detecting an absolute error increase: n ≈ ((Zα√(2p̄(1−p̄)) + Zβ√(p₁(1−p₁)+p₂(1−p₂)))²) / (p₁−p₂)², where p₁ is baseline error rate and p₂ = p₁ + Δerror.
How to use this calculator
- Enter a realistic production request rate and user count for the impacted service.
- Set your canary start, increment, max traffic, and the observation duration per step.
- Define guardrails using baseline error/latency and allowed increases.
- Choose confidence and power to approximate a minimum sample target.
- Submit to generate a schedule, review warnings, then export CSV/PDF.
Release goals and blast radius
A canary plan limits exposure while validating production behavior. Start with a small cohort, such as 5%, and translate that into users and requests. If 50,000 users are in scope, 5% affects about 2,500 users. At 200,000 requests/hour, 5% produces 10,000 requests per hour, so a two-hour window yields 20,000 requests to evaluate. Define success criteria: guardrails stable, alerts quiet, rollback ready.
Traffic ramp design
This calculator models a stepped ramp: pᵢ = start + (i−1)×increment, capped by a maximum. With 5% start, 10% increments, and a 50% cap, you reach 50% in six steps. Use smaller increments early; increase after stability holds. Step duration should match signal latency: choose 30–60 minutes for fast metrics, or 2–4 hours when queues, caches, or batch jobs influence outcomes. For multi-region services, ramp one region first, then broaden.
Guardrails and rollback triggers
Guardrails convert “healthy” into measurable thresholds. If baseline error is 0.30% and the allowed increase is 0.20 points, rollback triggers above 0.50%. For latency, a 250ms p95 baseline with a 15% allowance sets a 287.5ms threshold. Track sustained breaches rather than single spikes. Compare canary to control and watch saturation signals like CPU, memory, and queue lag.
Sample volume and confidence
Decisions improve with adequate sample size. The planner estimates a minimum request count per step using confidence (Zα) and power (Zβ) to detect a specified error-rate increase. Higher confidence or power needs more volume, so low-traffic services may need longer steps, fewer increments, or a higher canary ceiling. If traffic is constrained, accept a larger detectable delta by increasing the allowed error increase. Use the “Sample OK” column as a check, then validate with traces and impact metrics.
Operational readiness checklist
Before ramping, confirm dashboards, alerts, and ownership. Define who approves each step, what signals must stay stable, and when to pause. Capture links to runbooks, feature flags, and incident channels in release notes. Schedule ramps during staffed hours, and ensure the change can be isolated quickly. After reaching max canary, hold through typical load cycles, then proceed to 100% with the same guardrails. Export the schedule to fully align stakeholders and keep execution consistent.
FAQs
1) What does a canary release plan help you decide?
It helps you choose how much traffic to expose at each step, how long to observe, and which guardrails trigger a pause or rollback. The output is a repeatable schedule you can share.
2) How should I pick the starting percentage?
Start small enough to reduce impact, but large enough to produce meaningful signal. Many teams begin at 1–5% for high-risk changes, then increase once dashboards and alerts remain stable.
3) What step duration should I use?
Use a duration that matches how quickly your key metrics reflect change. If errors appear immediately, shorter windows work. If latency, caches, or async jobs dominate, choose longer windows to avoid false confidence.
4) What do confidence and power change in the plan?
They affect the estimated minimum samples needed to detect a specified error increase. Higher confidence or power raises the sample target, which may require longer steps or higher canary percentages to gather enough requests.
5) When should I enable auto-rollback?
Enable it when you have reliable guardrails and fast rollback mechanisms. Auto-rollback is most effective when thresholds are well-defined, alerting is tuned, and the deployment path can revert without manual intervention.
6) What are the CSV and PDF exports used for?
CSV is useful for importing the schedule into spreadsheets, runbooks, or change tickets. PDF provides a lightweight summary for approvals and handoffs, including thresholds, risk score, and step-by-step details.