LEARN. PRACTICE. GROW.Concept and mechanism
A canary exposes part of the service to a change and uses results to decide progression. It needs an appropriate population, comparison, criteria, and connection to the rollout decision. A sample without representative traffic may be green because it never exercised the changed behavior. Choose outcome, error, latency, capacity, and queue indicators according to the risk mechanism. Duration should permit observation of relevant patterns, including periodic tasks and peak load. No universal percentage or duration proves safety. If degradation signals appear, halt expansion and investigate or recover using agreed criteria before increasing the number of exposed users.
Guided application
In an original calculation, the canary has eight errors across 400 requests, or 2%; the control has 18 across 18000, or 0.1%. A global average can hide the difference. Also compare request mix and telemetry integrity before inferring cause. Blue-green maintains separate pools and shifts traffic, potentially combined with gradual progression; it requires capacity and shared-state compatibility. Separating servers does not undo database writes. Keep concurrent rollouts coherent: in GitLab, resource_group serializes covered jobs, but unordered mode does not guarantee order. An older release may still overwrite a newer one if ordering policy and protection against outdated jobs are not considered.
2% in the canary and 0.1% in the control warrant separate analysis even with a green pipeline.
Common pitfalls
Empty sample as success; global average; blue-green as data reversal; lock as ordering.
Related topics: Scope and coordination · Artifacts and traceability · Readiness and authorization
Connect exposure to observed health and retain control over change sequence.
Reference: Representative canary evaluation and feature exposure · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation