Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 681 of 80210. Deployment Strategies and GitOpsFree lesson

Automating Rollbacks with Health Probes

Integrate custom liveness and readiness checks to automatically trigger a revert when deployment metrics indicate performance degradation.

In this lesson, you will learn how to bridge the gap between application-level performance metrics and Kubernetes' self-healing capabilities to trigger automated rollbacks.

Moving Beyond Simple Connectivity

Up until now, you have used standard readinessProbes to confirm that a container is ready to accept traffic. However, in complex production environments, a pod might be "ready" in the eyes of TCP, but failing at the business logic level—such as high latency, database connection pooling errors, or memory exhaustion. Automating a rollback requires us to treat these performance degradations as deployment failures.

Bridging Health Checks and Argo CD

To automate a rollback when things go wrong, we configure Argo CD to monitor custom health checks. When a deployment occurs, Argo CD evaluates the health status of the resource. By defining a custom health.lua script within your Argo CD configuration, you can instruct the controller to mark a deployment as "Degraded" if specific telemetry thresholds are breached.

For example, you might define a health check that inspects your application’s /health/metrics endpoint. If the average request latency exceeds a predefined threshold (e.g., > 500ms), the custom probe returns a status of Degraded.

-- Argo CD Custom Health Lua snippet
hs = {}
hs.status = "Healthy"
if obj.status.metrics.latency > 500 then
  hs.status = "Degraded"
  hs.message = "Latency threshold exceeded: Automated rollback triggered."
end
return hs

Once Argo CD perceives the Degraded state, it interacts with the Kubernetes Deployment controller. If you have automated.prune and selfHeal enabled, combined with a rollback strategy, Argo CD will detect that the current live state violates your health policy and immediately revert the spec to the last known "Healthy" commit found in your Git repository.

By treating health probes as the "source of truth" for deployment success, you effectively shift the responsibility of production stability from manual oversight to an automated reconciliation loop. This minimizes the "Mean Time to Recovery" (MTTR) by eliminating human intervention during deployment failures.

Key Takeaway: By defining custom health assessment logic within Argo CD, you can programmatically trigger an automated revert to the last stable Git state the moment application performance metrics fall outside of defined operational boundaries.