The Pre-Deployment Checklist Every Engineering Team Is Getting Wrong

Every engineering team has a deployment checklist. Most of them are incomplete. That's the uncomfortable finding of a new survey from the DevOps Research Consortium, which polled 1,400 engineering leaders across mid-size and enterprise organizations and discovered that 78% of teams skip at least three steps that incident-response experts consider essential before pushing code to production. The result: a steady drumbeat of outages that cost companies an estimated $12.8 billion annually—and erode the trust that engineering organizations spend years building.

The survey, released this week, paints a picture of an industry that has invested heavily in CI/CD tooling but neglected the human and procedural elements that make deployments safe. Teams have automated their builds, their tests, and their delivery pipelines. What they haven't automated—or even formalized—are the judgment calls that sit between "all tests pass" and "we're confident this won't break production."

The most commonly skipped step, cited by 64% of respondents, is a documented rollback plan. Not a vague understanding that "we can revert if something goes wrong," but a written, tested procedure that specifies who initiates a rollback, what signals trigger it, and how long the process takes. "Everyone assumes they know how to roll back," said Janet Liu, VP of Engineering at a major fintech firm that participated in the study. "Then something breaks at 2 AM and it turns out no one has actually tested the rollback path since the database migration three months ago."

The second most-skipped step is a dependency audit—a review of every third-party library, service, and API that the new code touches. Fifty-seven percent of teams deploy without confirming that their external dependencies are healthy, versioned correctly, and compatible with the changes being shipped. This blind spot was responsible for the high-profile outage at a major e-commerce platform last November, when a routine deploy triggered a cascade of failures because an upstream API had silently changed its rate-limiting behavior two days earlier.

Canary deployments—the practice of routing a small percentage of traffic to the new version before a full rollout—came in third, skipped by 51% of teams. The reasons varied: some teams said their infrastructure didn't support it, others said it "slowed things down." But the data is unambiguous. Teams that run canary deployments experience 73% fewer severity-one incidents than teams that deploy all-or-nothing.

The survey also identified a dangerous psychological pattern: pipeline-induced confidence. When teams see green checkmarks across their CI/CD dashboards—tests passing, linting clean, security scans clear—they develop an outsized belief that the deploy is safe. But CI pipelines test what they're configured to test. They don't test for the unknown unknowns: the race condition that only manifests under production-level concurrency, the configuration drift between staging and production, the feature flag interaction that no unit test covers.

"The green checkmark is the most dangerous thing in modern software engineering," said Ravi Shankar, a site reliability engineer who consults with Fortune 500 companies on deployment practices. "It creates a false sense of completeness. Teams stop thinking critically because the machine told them everything is fine."

Load testing before deployment—not just during QA sprints—was skipped by 49% of teams. Configuration validation against the production environment (not just staging) was skipped by 44%. And a formal communication plan—notifying downstream teams, customer support, and on-call engineers that a deploy is happening—was absent in 41% of cases.

The recommended checklist, assembled from the survey data and interviews with incident-response leaders at companies including Stripe, Datadog, and Cloudflare, contains twelve items. Beyond the steps already mentioned, it includes: verifying that monitoring and alerting are configured for the specific changes being deployed, confirming that feature flags are in their expected states, reviewing database migration safety (particularly for schema changes that can't be easily reversed), and conducting a brief "pre-mortem"—a five-minute exercise where the team imagines the deploy has failed and brainstorms the most likely causes.

None of these steps are new. None of them require expensive tooling. What they require is discipline—and a culture that treats deployment as a high-stakes operation, not a routine button press. The survey found that teams with a formally maintained, regularly reviewed deployment checklist experienced 68% fewer production incidents and resolved those they did experience 40% faster.

"The irony is that speed and safety aren't in tension," said Liu. "The teams that deploy the most frequently with the fewest incidents are the ones that have invested the most in their pre-deployment process. The checklist doesn't slow you down. It speeds you up, because you spend less time fighting fires."