The Pre-Deployment Checklist: 10 Things to Verify Before You Ship
A 10-minute pre-deployment checklist for developers. 10 things to verify between merge and promote, plus what to hand off when time runs out.
We read every pre-deployment checklist on the first page of Google. Twenty-six items. Fourteen items. A 5,500-word essay framed as “seven essential steps.” All of them honest, all of them comprehensive, all of them unrunnable.
Every one of them was written for the person responsible for the deployment process. The SRE adopting a culture. The release manager owning the rollout. The platform team standing up the gate. None of them were written for the dev who just hit merge and has the next PR queued.
This one is. Ten items. Ten minutes. Scoped for the person who actually has to run it between merging and promoting, and honest about what the ten minutes cannot cover.
We wrote the abstract case for pre-production testing separately. This is the runnable version.
Why This Matters More Now
A few years ago, the dev hitting merge today was a dev writing maybe two hundred lines of code in a week. Today, with Cursor in one window and Lovable spinning up scaffolding in another, that number can be two thousand. Roughly half of working developers now regularly use AI coding tools, and most of it lands in the codebase without a human reading every line.
The merge-to-promote window is shrinking. Code velocity is up. Review capacity is roughly the same. Test capacity is roughly the same. The mismatch is not sustainable on hope.
The code review layer compounds it. The reviewer sees Copilot or CodeRabbit left comments, assumes the bot caught it. The bot is lossy. It catches the obvious and misses the subtle. By the time the PR merges, review has theoretically happened at three layers and substantively at zero.
The pre-deployment gate matters more now, not less. The 10 minutes between merge and promote is where you catch what your reviewer did not read carefully and what your bot scanner did not flag. It is the last cheap place to find a bug. The checklist the dev used to skip a year ago is the checklist they cannot afford to skip today, with AI-assisted code shipping at multiples of human-written cadence.
Skip the checklist entirely
See what runs on every PR when Pie Loop covers the pre-deployment gate.
Book a DemoThe 10-Minute Pre-Deployment Check
Ten items, about a minute each. The first three verify what is about to ship. The next four gate-check what is about to happen. The last three handle ship and observe.
1. Confirm CI is green on the merge commit, not just your PR branch (30 seconds)
Your PR was green an hour ago. You merged it. The merge commit re-ran some checks. One of them silently failed. You did not notice because you were already looking at the next PR.
Verify every required check is passing on the merge SHA, not just on your branch tip. GitHub’s merge queue surfaces this; if you are not on a merge queue, click into the commit and look at the check icons. This catches the “stale base merge” trap, which is the single most common silent failure between merge and promote.
2. Re-read your PR description against the actual diff (60 seconds)
You wrote the description three days ago. The diff has grown. The description still says “small refactor.” It is not, anymore.
Verify the description still matches what the diff does and what the PR title claims. If you added a migration mid-review, the description should say so. If the diff is twice as big as when you opened the PR, your reviewer’s mental model is out of date too. This forces a context-reload before any other call.
3. Skim what is bundled into this deploy versus what is in your PR alone (60 seconds)
If your team batches multiple PRs into one deploy (most do), other people’s changes are about to ride your promote. You are partly responsible for theirs, even if you did not review them.
Scroll the deploy diff or the merge train. Recognize each PR by author and one-line description. If you see something unfamiliar, flag it in your team channel before promote, not after.
4. Click the changed feature on staging once (90 seconds)
Open the staging URL. Click the critical path of the feature you changed. Watch it load. Watch it behave. Confirm it does not visually regress.
Call it the dev’s smoke test. It is not deep. It catches the obvious break. An empty state that 500s. A button that is now a 404. A network call that returns the wrong shape. Dev tools open, network tab visible, console clean. If staging is broken, that is the actual finding. File a ticket before promote, because shipping into a known-broken staging is shipping into uncertainty.
5. Confirm secrets and env config in prod match what staging used (60 seconds)
The classic “works on staging, breaks in prod” lives here. A missing env var. A different API key. A third-party endpoint pointing somewhere else.
Spot-check two or three env vars your change relies on. The ones added in this PR are the highest risk. If your platform does not expose an env diff between environments, ask DevOps to add it. Once.
6. Confirm feature flag state matches your intent (30 seconds)
- New feature — flag off by default, on for internal users only.
- Migration — flag in a known state at promote moment.
- Sunset — confirm the cohort the flag affects, not just that the flag exists.
Open the flag dashboard, eyeball the state for the relevant environments. Thirty seconds prevents the worst class of incident, the one where the feature ships but nobody knows whether it is actually live.
7. Check your error tracking dashboard for baseline noise (60 seconds)
Without a baseline reading before promote, you cannot recognize a spike after. Sixty seconds is just opening the dashboard once and noting the number.
Open Sentry, Honeycomb, Datadog, whatever your team uses. Note the current error rate. You will compare against this five minutes after promote. If you did not look before, you have nothing to compare to. The dashboard reading is the reference point that makes the post-deploy watch meaningful.
8. Have the rollback command in a tab (30 seconds)
Open the rollback path now. The button. The CLI command. The ChatOps message. Whatever your platform uses.
After the incident is the worst time to learn the rollback flow. You are stressed, the team is asking questions, and you are hunting through docs to find a command you have used twice. Open the tab now. Thirty seconds, massive optionality.
9. Drop a one-liner in the deploy channel (30 seconds)
“Promoting #234 in five minutes. Small feature flag flip, low risk. Pinging @oncall just in case.”
When something breaks, the team has context. Silent deploys make incidents slower because responders have to first figure out what changed. Calibrate tone to your actual confidence; if you are nervous, say so. That is data, not weakness.
10. Watch the first three to five minutes of post-deploy logs and errors (3 minutes)
After you hit promote, do not close the laptop. Open the log stream and the error dashboard. Watch them for three to five minutes.
Watch for an error rate spike against the baseline you noted before promote, unfamiliar exception patterns, or 5xx surges on the routes you touched. Most post-deploy incidents announce themselves in the first few minutes. They are the class of defect that only real traffic surfaces. Three minutes here saves an hour of incident response if something is wrong, and confirms a clean deploy if it is not.
Two quick definitional notes before what 10 minutes cannot cover.
Pre-Deployment vs Pre-Release
These terms get used interchangeably, but they are not the same gate.
Pre-deployment is the per-push code safety gate. It runs every time you ship, sometimes ten times a day. The dev owns it. This checklist is for that gate.
Pre-release is the per-version product readiness gate. It runs at the cadence of a release: weekly, sprint-end, or App Store submission. QA or release management owns it. It includes changelogs, release notes, App Store metadata, and support enablement that this checklist deliberately does not touch.
If you own the version-level gate, the pre-release checklist for QA teams is a different post (a separate one we are writing for that audience).
What 10 Minutes Cannot Cover
A 10-minute hygiene pass catches the obvious breaks. Four categories of issues consistently fall outside what it can reach.
- Full regression coverage. The checklist tells you to click the feature you changed. Everything else in your app that shares a dependency with your PR runs untested until users encounter it.
- Production data edge cases. Staging accounts are clean by design. Real user records have accumulated state, legacy fields, and edge-case combinations that test data was never written to cover.
- Integration contract drift. Checking whether env vars are set confirms configuration. It does not confirm that your payment processor or auth service is behaving the same way against production credentials as it did in staging.
- Long-tail failures. The post-deploy log watch catches what breaks in the first few minutes. Failures that only surface after a user reaches a specific account state, or after sustained usage, sit outside that window.
Most teams handle this gap with one of three options: a small QA team running a longer pass, a maintained script suite on a device farm, or hope. If you do not have the first two, you have been quietly running on the third.
How Pie Loop Closes the Gap
We built Pie Loop because the 10-minute check leaves a real gap, and most teams are filling it with hope.
You merge a PR. Pie Loop runs the deep pre-production check autonomously, exploring the surface area your CI does not touch, navigating the multi-step flows the 10-minute pass cannot reach. If it finds a regression, the fix surfaces as a suggestion inside your IDE. You accept it, ship the fix in the same flow, promote.
A working pre-production gate looks like this. The hygiene pass stays human, fast, and runnable. The deep coverage runs in parallel. The dev shipping the next PR does not have to choose between thoroughness and speed.
Or skip the 10-minute hygiene check entirely. If Pie Loop runs on every PR, the manual pass becomes optional and the 10 minutes go to the next feature.
Ship Without Crossing Your Fingers
A pre-deployment checklist is only useful if you will actually run it. Build a 10-minute version that fits between merge and promote. Sequence it for the person doing the running. Be honest about the gap.
For everything the 10 minutes cannot reach (the regression in an untouched flow, the locale-specific crash, the third-party drift, the multi-step flow that needs an hour of state setup) you need autonomous QA that runs while you do something else. That is the layer the industry has been missing, and it is the layer that makes the rest of the deployment process feel less like crossing your fingers.
Add the pre-production gate
See what Pie Loop catches on your next PR. Connect your repo. First gate runs in hours.
See It in ActionFrequently Asked Questions
Eight years building search and delivery systems at Amazon. The kind of scale where flaky tests block billion-dollar releases. Now CTO at Pie, building AI agents that adapt when your UI changes. LinkedIn →