loading
loading
Releasing a change to a tiny slice of traffic first, so failures surface before they hit everyone.
From the canary in a coal mine: you route a small percentage of users to the new version, watch error rates and latency, and only ramp up if it stays healthy — otherwise you pull it after burning a fraction of users instead of all of them. Usually driven by feature flags or weighted routing. Example: send 2% of API calls to a new model, compare quality and cost, expand if it holds. A canary that dies is a successful canary — it caught the problem early.
Plainly
Think of Canary as the checklist that keeps the app open for real people. Releasing a change to a tiny slice of traffic first, so failures surface before they hit everyone.
In practice
Use it when a change has to survive deploys, users, incidents, analytics, or billing reality. In practice, define the owner, input, output, and failure mode before you rely on it.