Canary release

A canary release sends a new version to a small share of users first, watches how it behaves, and widens the audience only if the metrics stay healthy.

In a canary release, the new version and the current version run in production at the same time. A small group of users receives the new one. The team compares error rates, performance and business metrics between the two groups. If the numbers look good, the share grows in stages until everyone is on the new version. If they look bad, the small group goes back to the current version, and most users never noticed anything.

The name comes from the canaries that miners carried to detect dangerous gas early.

Example

A platform loads its micro-frontends from a manifest. To release a new version of the checkout remote, the server that delivers the manifest returns the new remote URL to a small percentage of sessions and the current URL to the rest. Frontend error tracking is tagged with the remote version. After an hour without new errors the share is raised, and later it reaches all sessions.

Common misunderstanding

A canary is sometimes confused with an A/B test. Both split traffic. An A/B test compares two product ideas to learn which one performs better. A canary checks that one new version is safe, and it ends with everyone on the same version.

A canary also has no value without measurement. If nobody watches error rates per version, or if the frontend does not report errors at all, the release is only a slow rollout. Decide in advance which metrics count and which threshold triggers a rollback.

One frontend detail matters: a user should stay in the same group for the whole session, so that the page never mixes chunks from two versions. See micro-frontends for how the manifest makes this possible.

Related terms

• Feature flag
• Blue-green deployment
• Rollback