Yes, for fixes that touch services with real traffic. A canary sends a merged dependency fix to a small slice of production first and compares it against the rest. It catches runtime problems that tests miss, limits the damage of a bad fix, and gives you a clear rollback trigger.
Definition
Google's SRE workbook defines canarying as a partial and time-limited deployment of a change in a service and its evaluation. The canary gets the change, the rest of the service acts as the control, and the comparison decides whether the rollout continues.
For security fixes this means: merge the fix, deploy to a small share of instances or traffic, watch a few signals, then widen or revert.
Why dependency fixes need it
Tests describe the behavior you thought to test. A dependency update can change performance, memory use, error handling or timing in ways no unit test covers. Staging rarely matches production load. A canary is the cheapest way to find out with real traffic.
How to set one up
- Pick a small population. Small enough that a defect affects little traffic, large enough to show real differences. The SRE guidance notes that impact on error budget scales with the fraction of traffic exposed.
- Choose a few strong metrics. The workbook advises metrics tied to service level indicators, such as error rate and latency, that signal real user problems and are attributable to the change.
- Match metric intervals to the window. Make sure the intervals of your metrics are the same as or shorter than the canary duration.
- Set the duration. Long enough to be representative. A deploy at an off peak hour can miss load related defects.
- Run one canary at a time. The authors strongly advise it, so results can be attributed.
- Define rollback before you start. Write the threshold that triggers it, and who decides.
What to watch for a dependency fix
| Signal | What it can reveal |
|---|---|
| Error rate | Behavior change or failed initialization |
| Latency percentiles | Slower code paths in the new version |
| Memory and CPU | Leaks or heavier processing |
| Startup time and restarts | Crash loops, missing runtime pieces |
| Dependency specific logs | Deprecation warnings, new exceptions |
Where canarying does not fit
Libraries shipped to customers, desktop software and mobile apps cannot be canaried in the same way, although staged rollouts serve a similar purpose. Batch jobs that run once a night need a different pattern, such as a dry run on a copy of the data. Pick the nearest equivalent rather than skipping the step.
Tie it to the fix workflow
A security fix creates pressure to ship fast. Decide ahead of time that fixes for services above a certain criticality go through the canary stage, and that urgent exploited issues may compress the window but not remove it. Record the canary result with the fix, since it is evidence that the change was verified in production conditions.
If the canary fails, revert the fix and reopen the finding with an owner and date, plus a temporary mitigation.
Safeguard offers autonomous remediation with fix PRs, off by default with every category on Manual. Your deploy pipeline, including any canary stage, stays in your hands.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change moves from finding to a gated decision.
Quick check
How long should a canary run?
Long enough to be representative for your traffic pattern. Pick a duration in advance and make your metric intervals no longer than it.
Can I run several canaries at once?
The SRE guidance advises running only one at a time, so you can tell which change caused a problem.
Sources
Last reviewed: 19 October 2026.
