Canary Deployment
A canary deployment sends a small share of real users or traffic to a new version first. Evidence decides whether to expand or stop.
stable + small canary share -> observe gates -> promote, pause, or abort95%Canary v25%- ✓Error rate
0.3% ≤ 1% - ✓p95 latency
380 ≤ 500 ms - ✓Checkout success
stable
stable + small canary share -> observe gates -> promote, pause, or abortOPSAnother example
Version 2 receives 5% of checkout traffic. The team watches errors and latency for ten minutes. A failed limit stops the rollout.
Main parts
- 01Stable version
- 02Canary version
- 03Traffic or audience share
- 04Observation window
- 05Success and stop limits
- 06Promotion or abort
Use it when
Use a canary when production behavior matters and traffic can split safely. Define audience, steps, signals, limits, wait time, and rollback.
Do not use it when
Do not call every slow rollout a canary. A chosen group must test the change, and results must guide promotion.
Name used in code
stable + small canary share -> observe gates -> promote, pause, or abort Before you ship
Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback.
Outcome: Use Canary Deployment to release or recover the change safely, with a clear record. User context: Version 2 receives 5% of checkout traffic. The team watches errors and latency for ten minutes. A failed limit stops the rollout. Delivery concept or operation: Canary Deployment. Why it fits: Use a canary when production behavior matters and traffic can split safely. Define audience, steps, signals, limits, wait time, and rollback. Do not use it when: Do not call every slow rollout a canary. A chosen group must test the change, and results must guide promotion. Delivery requirements: Name the code repository and target. List preconditions, changes, review and CI checks, conflict and data-loss risks, release order, and the rollback or recovery command. Repository safeguards: Keep unpublished work and a clear history. Do not run destructive steps without an explicit backup. Check the exact code diff and remote target before publishing. Acceptance criteria: Review the intended diff and pass all required checks. Keep the target version traceable. Practice failure recovery and keep published history clear. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Repository, branch, team activity, release environment, approval owner, protected checks, and rollback target.
Check this request
Review the current use of Canary Deployment. Definition: A canary deployment sends a small share of real users or traffic to a new version first. Evidence decides whether to expand or stop. Release checks: Before publishing, check the exact repository, branch, target, and diff. Keep unpublished work. Pass review and CI checks. Record conflict and data-loss risks, release order, traceability, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.