Yes, with kubectl rollout pause, but it is not an emergency brake. A paused Deployment ignores later changes to its pod template until you resume it. It is meant for batching edits, so it will not undo a release that has already started.
What pausing does
The Kubernetes documentation describes pausing as a way to apply multiple fixes between a pause and a resume without triggering unnecessary rollouts. The spec.paused field is the only difference between a paused Deployment and a normal one: changes to the pod template will not trigger new rollouts while it is paused. In its example, the image is updated while paused, and no new rollout starts.
That means pause is useful before a change, not after a bad one. If a rollout is already halfway through, pausing leaves it halfway.
Pause, undo or scale: which tool when
| Situation | Better tool | Why |
|---|---|---|
| You want to batch several edits into one rollout | Pause, edit, resume | Avoids intermediate rollouts |
| A release is bad and the previous version is acceptable | Rollout undo | Restores the earlier pod template |
| A release is bad and the previous version is vulnerable | Fix forward, restrict exposure | Undo may reopen a known hole |
| A component must stop serving now | Scale down or cut traffic at the edge | Pause does not remove running pods |
| You want to stop automation from changing a Deployment | Pause, plus pause your GitOps sync | Controllers may keep reapplying changes |
The documentation notes a rollback restores only the pod template and that scaling does not create a revision, so scaling is a separate lever.
A security use for pause
When responding to an advisory, you may need to change an image, an environment variable and a resource limit together. Pausing, making all three edits, then resuming gives one clean rollout and one revision. That makes later rollback and audit easier, because each revision maps to one decision.
kubectl rollout pause deployment/web
kubectl set image deployment/web web=registry.example.com/web@sha256:DIGEST
kubectl set env deployment/web FEATURE_X=off
kubectl rollout resume deployment/web
kubectl rollout status deployment/web
The digest above is a placeholder. Use the real one from your release record.
Watch for these traps
- A paused Deployment is easy to forget. Add an alert or a daily report of paused Deployments, so a fix does not wait unseen.
- Pausing the Deployment does not stop a GitOps tool from trying to apply changes. Decide how your tool treats a paused object.
- Pausing does not protect you from other ways pods are created, such as a node drain recreating pods from the existing template.
Record why
Whenever you pause, note the reason and owner in your incident record. The documentation shows a kubernetes.io/change-cause annotation that is copied to revisions, which helps explain later what each revision was for.
Where Safeguard fits
Safeguard's autonomous remediation can propose fix pull requests for dependencies. It is off by default and every category is on Manual, so a person reviews each one. You can then roll the fix out as one batched, well documented revision. A free scan shows what a first pass finds.
Quick check
Will pause stop a rollout that is already in progress?
Pausing is intended to prevent new rollouts from starting on template changes. For a bad release already going out, use undo, scale or traffic controls.
Why would I pause before a security change?
To batch several edits into one rollout and one revision, which keeps history clear.
Sources
Last reviewed: 19 October 2026.
