Four Simple Practices to Improve Deployment Reliability and Reduce Downtime

When deploying code, the two biggest challenges are minimizing work and avoiding downtime while also being able to verify that services are running correctly and configured as expected.

The author proposes four simple actions that can be applied in any environment to improve the deployment process, increase confidence, and ensure applications are correctly running and configured.

Application Health Check

The first step is to confirm that an application is up, ready to serve, running the expected version, and able to connect to downstream services or databases. A common pattern is to expose a /public/health endpoint that returns JSON indicating health status, commit hash, uptime, and connection status.

{
  "healthy": true,
  "commit": "1e98e46",
  "uptime": "05:22:47:21",
  "connection_status": true
}

This health check can be used during blue‑green deployments to verify that the newly deployed version matches the intended commit and that all connections are healthy before promoting the deployment to production.

In the author’s experience with AWS ECS, mismatched commit IDs caused deployment failures that were quickly identified by the health‑check endpoint, saving over 30 minutes of troubleshooting.

Event Annotation

Recording deployment events and annotating them in monitoring systems (e.g., Grafana) helps quickly correlate performance spikes or failures with specific releases. Adding annotations for backups, configuration changes, or other operational actions further narrows the root‑cause investigation.

By consistently logging every change—whether automated or manual—teams gain a clear timeline of what happened and why, making it easier to spot the impact of a particular event.

Pod: Minimise Impact

Designing applications and infrastructure around pods (whether Kubernetes pods, VM‑based pods, or logical groupings) allows failures to be isolated to a subset of users or regions. Multi‑tenant or multi‑region pod deployments ensure that an outage in one pod does not affect the entire user base.

When pods are isolated, a cloud‑region failure or a problematic deployment only impacts the customers assigned to that pod, preserving overall service availability.

Blue‑Green Deployment

Blue‑green deployment runs two versions of an application simultaneously, routing live traffic to one version while the other is staged for upgrade. Compatibility between versions, especially database schema compatibility, is essential.

In AWS, an Application Load Balancer can hold two listener rules—one for the blue version and one for the green version. Switching the rule promotes the new version, and the old version is drained only after the health check passes.