Release lag is the time between a build reaching staging and the same build reaching production. A short, steady lag is healthy because it gives testing time. A long or growing lag is drift in time: staging fills up with changes that production lacks, including security fixes. Set a limit and track it.
Why lag becomes a security issue
When a dependency fix lands in staging but production waits weeks, production carries the vulnerable version for that whole period. Meanwhile staging keeps moving, so the next release is bigger and riskier, which pushes the lag longer still. It is a loop.
How to measure it
- For each service, record the timestamp when each release is first deployed to staging and to production.
- Compute the gap per release, and the current gap: the age of the oldest change that is in staging but not in production.
- Track the median and the worst case per month. A median hides stuck services, so keep the maximum visible.
- Break out security related changes, such as dependency bumps, and measure their lag separately.
| Metric | What it tells you |
|---|---|
| Median lag | Normal flow |
| Maximum lag | The service that is stuck |
| Security change lag | How fast fixes actually ship |
| Count of unpromoted releases | Batching |
Setting a limit
There is no universal number. Pick one that fits your testing and approval flow, write it down, and make exceeding it visible. A common pattern is a short limit for security fixes and a longer one for ordinary changes. Ask your engineering leads to agree on the numbers instead of choosing them in a security meeting.
What stretches the lag
- Manual approvals with no owner or backup.
- Slow or flaky end to end tests that people wait on.
- Change freezes that are never lifted.
- Large batches, because each deploy feels risky.
- Environments that depend on shared data being in a certain state.
Fix the cause. Shrinking batch size usually helps most: smaller changes are easier to approve and to roll back.
What to do when the lag is already long
- List every difference between staging and production for the service.
- Rank them by risk, using which drift is a security risk.
- Ship security fixes first, as their own small release if possible.
- Then work down the list.
Do not close the gap by skipping tests. That swaps one risk for another.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings carry age and status. Lag in shipping a fix is visible if you track those fields.
What Safeguard does here
Safeguard tracks vulnerabilities and fix availability across projects, and can open fix pull requests, with autonomous remediation off by default and every category on Manual. That makes the time between a fix existing and a fix shipping easier to see. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is zero lag the goal?
Not necessarily. Some lag is useful for testing. Aim for a short, predictable gap.
Who owns lag?
The service owner, with platform or release engineering supporting.
Last reviewed: 19 October 2026.
