Base canary decisions on enough comparable requests
A release automatically promotes after five error-free canary requests while the stable version serves thousands. Low traffic makes an untested version look healthy.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Release analysis · Measurement design · Decision systems · Observability
Estimated field mix
- Site reliability40%
- Platform engineering40%
- Performance engineering20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional scheduling service has an API, a worker, and PostgreSQL. Releases use immutable images on two application instances. The team needs compatibility checks, staged traffic, and a rehearsed rollback without introducing a new orchestration platform.
Setup prerequisites
- HTTP health checks
- CI pipelines
- Database migrations
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- ROLL-102 · Separate liveness from database readiness
- ROLL-101 · Display the exact release identity in diagnostics
- ROLL-103 · Refuse deploys with incomplete runtime configuration
- ROLL-104 · Keep old API instances working during a column rename
- ROLL-105 · Prevent two release jobs from overwriting the same environment
Acceptance criteria
- Require a configured minimum request count and observation window before promotion.
- Compare matching route classes with error-rate and latency budgets declared in the fixture.
- Return HOLD for insufficient traffic and ABORT for breached safety thresholds.
Implementation constraints
- Use bounded route labels; a percentage alone cannot justify a decision without sample counts.
Verification to include
- Promote a synthetic canary with adequate comparable traffic.
- Exercise sparse traffic, a route-mix shift, and rising errors; inspect HOLD or ABORT reasons.
Deliverables
- Canary decision function, fixture traces, and decision report
Rollout and recovery
Run decisions in observe mode against simulated traffic before allowing the simulated provider to advance stages.
Value of the work
For the engineer: Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology.
For the team: Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.