Zero-Downtime Deployments: The Checklist Every Team Needs

Zero-downtime deployments aren't magic. They're the result of disciplining yourself to follow a checklist. Every. Single. Time. Here it is:

Before You Deploy

- Database migrations are backward-compatible (no column renames or drops without a multi-step migration)

- Feature flags wrap any breaking changes

- Health checks are configured and actually test meaningful functionality

- Readiness probes distinguish between "starting up" and "ready for traffic"

During Deployment

- Rolling update strategy is configured (maxUnavailable: 0, maxSurge: 1 minimum)

- Connection draining is enabled (give in-flight requests time to complete)

- New pods pass health checks before old pods are terminated

- Load balancer is aware of the deployment (no traffic to terminating pods)

After Deployment

- Smoke tests run automatically against production

- Error rate monitoring has a threshold that triggers automatic rollback

- Deployment is announced in your team's channel with a link to the diff

- Rollback is one command away and tested within the last 30 days

The Most Common Failure: Not testing rollbacks. Everyone tests deploys. Almost nobody tests rolling back. Schedule a rollback drill monthly. Your future 3 AM self will thank you.

Save this checklist. Print it. Tape it to your monitor.

Everyone on tech Twitter acts like Kubernetes is a given. The actual data is more nuanced.

By company size (2026 survey data):

• 1-50 employees: ~18% running K8s in production (down from hype-driven 25% in 2024 — many migrated back to simpler solutions)

• 50-500 employees: ~52% with at least one production cluster

• 500-5000 employees: ~78% running K8s, most with dedicated platform teams

• 5000+ employees: ~91% — it's essentially table stakes at enterprise scale

The key insight: Kubernetes adoption is increasingly bimodal. Large orgs are going deeper (multi-cluster, service mesh, GitOps). Small orgs are going simpler (back to ECS, Cloud Run, Railway, Fly.io).

The middle is where it gets interesting. Mid-size companies are the ones making the hardest decisions right now. Big enough to benefit from K8s, small enough that the operational overhead hurts.

If you're in that 50-500 range — what did you choose and why? The answer matters more than any blog post.

Your staging environment gives you false confidence. Here's why.

The data is fake. Staging has 1,000 rows. Production has 100 million. That query that takes 2ms in staging? It takes 45 seconds in prod and locks your main table.

The traffic is fake. You test with 1 user clicking through the app. Production has 10,000 concurrent users hitting the same endpoint. Your race conditions and connection pool limits only show up under real concurrency.

The infrastructure is smaller. Staging runs on t3.medium. Production runs on c5.4xlarge with autoscaling. The bugs you hit in production don't exist in staging because the failure modes are completely different.

The integrations are mocked. Your staging Stripe webhook uses test mode. Your staging email provider is a black hole. The third-party API that rate-limits you in production returns instantly in staging.

So what do you actually do?

1. Test in production with feature flags and canary deployments

2. Use production database snapshots (anonymized) in staging

3. Load test against staging with realistic traffic patterns

4. Shadow traffic — mirror production requests to staging without serving responses

5. Accept that staging is for development, not for confidence — your real safety net is observability + fast rollbacks

Staging isn't useless. But treating it as proof that your code works in production is how outages happen.

This debate has been going on for years, but 2026 brought some real shifts. Here's where things actually stand.

GitHub Actions wins on:

• Marketplace ecosystem (180K+ actions)

• Native integration with the largest code hosting platform

• Larger runner fleet with GPU and ARM support

• Better for open source (free minutes for public repos)

GitLab CI wins on:

• Built-in container registry, package registry, and artifact management

• DAG pipelines with explicit dependency graphs

• Self-hosted runner management at scale

• Security scanning built into the pipeline natively

The real answer: If you're already on GitHub and your pipelines are straightforward, Actions is the path of least resistance. If you need a fully integrated DevSecOps platform and you're willing to manage more infrastructure, GitLab CI is more powerful out of the box.

The worst choice? Migrating between them without a clear reason. What's your team running?

If your team is deploying less than once a day, there's a good chance one of these anti-patterns is the culprit.

1. The Mega-Pipeline

You've got a single pipeline that builds, tests, lints, scans, and deploys everything in sequence. A failure at minute 38 means starting over. Break it into parallel stages with clear ownership.

2. Manual Approval Gates Everywhere

One gate before production? Fine. Three gates across staging, QA, and pre-prod? You've built a bureaucracy, not a pipeline. Automate confidence with tests, not human sign-offs.

3. Environment Drift

Your CI passes in a container that looks nothing like production. IaC your CI runners the same way you IaC your infrastructure. If it works in CI but fails in prod, your CI is lying.

4. Flaky Test Tolerance

"Oh, that test is just flaky, re-run it." Every flaky test you tolerate is a crack in your confidence. Quarantine flaky tests, fix them, or delete them.

5. No Rollback Strategy

If your only rollback plan is "revert the commit and re-deploy," you're one bad merge away from a 2-hour outage. Blue/green, canary, or feature flags — pick one and drill it.

Which of these is your team guilty of? Be honest.

DeployDigest is a weekly newsletter built for DevOps engineers and SREs at mid-size companies.

Every Tuesday, you'll get a deep-dive into topics that matter:

• CI/CD pipeline optimization

• Kubernetes & container orchestration

• Infrastructure-as-Code best practices

• Observability & incident response

• Platform engineering trends

Plus, you get access to a private community of practitioners who actually build and operate production systems.

£5/month — use code LAUNCH25 for 25% off your first 3 months.

Stop drowning in Hacker News threads. Get the signal.