Automated rollback
Automatically restoring the last known-good release when post-deploy checks or production metrics show the new one is failing.
What it is
An automated rollback watches a new release during a defined bake time and restores the last known-good version when a check crosses a failure threshold. A failed smoke test, rising error rate, or broken health check becomes a machine decision instead of a 2am judgment call. Argo Rollouts can run an AnalysisTemplate during a canary and send all traffic back to the stable ReplicaSet when the analysis fails.
Reach for it when releases are frequent, the old artifact stays ready, and failure can be measured quickly and unambiguously. It is especially useful for canary and blue-green releases, where returning traffic to the stable version is already a cheap routing change.
Gotcha: code can roll back while data cannot. A destructive migration, sent email, or completed payment survives the version change. Noisy thresholds can also create rollback loops during an unrelated outage, so compare the new release with a stable baseline and require a short window of sustained failure rather than one bad sample.
Ask AI for it
Add automated rollback with Argo Rollouts and a Prometheus AnalysisTemplate. During the canary, compare HTTP 5xx rate and p95 latency for the canary and stable ReplicaSets every minute for a 10-minute bake window. Set explicit successCondition and failureCondition expressions, set failureLimit to 3 before aborting, and on failure route 100% of traffic back to the stable ReplicaSet. Keep the failed revision for diagnosis, send a notification with the metric values, and document the manual abort and retry commands.