A new release must not affect all users at once, and failures must be detected quickly. What do you do?
Why C is the answer
Canary the release with alerts tied to SLOs
Progressive release with SLO-based alerts limits the blast radius and catches problems early.
In detail
- A canary limits exposure.
- Alerts tied to user-facing symptoms catch failures quickly.
- Tie alerts to what users feel.
Use case
An illustrative scenario, not a real incident.
A release reaches 5% of users. An SLO alert fires, and the team rolls back before most users notice.
See it in different ways
flowchart LR
A["Deploy to a canary"] --> B{"Metrics healthy?"}
B -->|Yes| C["Roll out further"]
B -->|No| D["Roll back"]sequenceDiagram participant D as Developer participant P as CI/CD pipeline participant C as Canary participant U as All users D->>P: Reviewed change P->>C: Small share of traffic C-->>P: Alerts on user-facing symptoms P->>U: Complete the rollout, or roll back
stateDiagram-v2 state "Canary" as s0 state "Full rollout" as s1 state "Rolled back" as s2 [*] --> s0 s0 --> s1: SLOs hold s0 --> s2: alert fires s1 --> [*] s2 --> [*]
Key point: Canary with SLO alerts limits impact.
Why the other options are wrong
- A. Skip monitoring during the rollout to reduce alert noise
- Monitoring is what detects failures.
- B. Test only in development, then release to everyone
- Development cannot show production behavior.
- D. Release everything on one night with the team on call
- That exposes everyone at once.