deployment-canary

Deployment Canary

A release is not done when it is deployed — it is done when it survives contact with real traffic. This skill formalizes the canary phase between "ship" and "fully rolled out": define what healthy looks like, watch the right signals, and rollback fast when the evidence says to.

When to Use

• After deploying a new version behind a canary, percentage rollout, or feature flag
• Before promoting a release from a small traffic slice to full production
• When the release changes critical paths: auth, checkout, billing, queueing, migrations
• When a team needs explicit rollback criteria instead of "watch the dashboard and hope"

When NOT to Use

Instead of deployment-canary	Use
Packaging a library with no runtime environment	release plus smoke install checks
Diagnosing an already-confirmed incident	systematic-debugging
Deciding whether to ship at all	council or launch-strategy

Prerequisites

• The release has a unique identifier: image tag, build SHA, version, or feature flag
• You know the canary scope: percentage of traffic, tenant list, region, or cohort
• Dashboards, logs, or health checks exist for the affected system
• A rollback path is available before promotion starts

Workflow

1. Define the Canary Contract

Before watching dashboards, define the exact terms for success and failure:

> Prepare a canary contract for release [version/build]:
> - Scope: what percentage, which region, or which customer cohort
> - Watch window: how long the canary must stay healthy
> - Primary signals: error rate, latency, saturation, business KPI
> - Rollback triggers: exact thresholds that stop promotion
> - Owners: who decides promote / hold / rollback

At minimum, define:

• Scope — e.g. 5% traffic, one region, internal users only
• Window — e.g. 30 minutes, 2 hours, one business cycle
• Signals — system health + user outcome + business impact
• Thresholds — e.g. error rate +1%, p95 latency +200 ms, failed checkout rate above baseline