After a fix is merged, deploy time is set by five things: how the pipeline is triggered, any approval or wait gates, how long the rollout takes, whether images must be rebuilt, and how long verification takes. Each can be measured and each can be shortened without removing the safety it provides.
Define the deploy stage
The deploy stage starts when the fix is merged and ends when the patched version is serving production traffic. DORA's research describes change lead time as the time it takes a change to go from committed to version control to deployed in production. Deploy time is the tail of that measure, and it sets a floor under your exposure window for any vulnerability you fix in code.
The five controls
| Control | What it adds | How to shorten safely |
|---|---|---|
| Trigger | Waiting for a release train | Deploy on merge for security fixes |
| Approvals | Time until a reviewer clicks | Define who can approve, and a response target |
| Rollout | Rolling replacement of instances | Tune surge and availability settings |
| Rebuild | Base image and dependency refresh | Rebuild with fresh layers on fix |
| Verification | Smoke tests and watch period | Automate the checks you run by hand |
Approvals
GitHub documents that a deployment job can wait for review, and that required reviewers and wait timers are deployment protection rules on an environment. Protection rules are good controls. They also create queues. Name backup reviewers, and give security fixes a stated response target so a job is not waiting on someone on leave.
Rollout settings
In Kubernetes, the Deployment documentation explains that a rolling update keeps the number of available replicas between replicas minus maxUnavailable and replicas plus maxSurge, and that maxUnavailable defaults to 25 percent. It also describes minReadySeconds, the time a new pod must be ready before it counts as available, which defaults to zero, and progressDeadlineSeconds, how long the controller waits before reporting that progress has stalled. A long minReadySeconds is a deliberate safety margin that also lengthens every rollout, so choose it on purpose.
Rebuilds
Docker's guidance on building images says images are immutable snapshots, that a tag such as a base image version can resolve to a different underlying image over time, and that you should rebuild regularly. It describes a pull flag to fetch a newer base image and a no cache flag to re-run build steps, noting they serve different purposes. If your fix lives in the base image, a cached build will quietly redeploy the old one.
docker build --pull --no-cache -t my-image:my-tag .
What to measure
Record three timestamps per fix: merge, deploy start and deploy complete. Then compute merge to start (queue time) and start to complete (rollout time). Queue time usually dominates, and it responds to process changes rather than technology changes.
Try it yourself
Open the container scan demo and look at how an image is checked, which tells you whether a rebuilt image really contains the fix.
Click through it at your own pace, or open it full screen.
Safeguard supports container image scanning and policy gates, so you can check the rebuilt image before it ships. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a faster rollout always better?
No. Rollout settings trade speed for safety. Tune them, and keep the checks that catch bad releases.
How do I know the fix really shipped?
Verify the running version or image digest, not the merge status.
Sources
- DORA's software delivery performance metrics
- Reviewing deployments, GitHub Docs
- Deployments, Kubernetes documentation
- Docker build best practices
Last reviewed: 19 October 2026.
