What I Check Before Every Deployment

I broke production on a Friday afternoon once. Pushed a config change that looked fine in staging but referenced a dev database URL in one environment variable.

Took the whole site down for 40 minutes. On a Friday. At 4 PM. My phone did not stop buzzing.

Since then, I have a checklist. It's not long. But I follow it every single time. No exceptions. Not even for "it's just a small CSS fix."

The Checklist

1. Diff the Changes

Before deploying, I look at exactly what's going out. Not what I think changed — what actually changed.

git diff main...HEAD

I compare the diff against what I intended to change. If there's something in the diff I didn't expect, I stop and figure out why.

This has caught accidental debug logging, leftover test data, and environment config changes that I didn't realize were staged.

2. Validate Config Files

JSON config files are fragile. One missing comma breaks everything, and the error message usually says something unhelpful like "Unexpected token."

I paste every modified config file into a JSON validator before deploying. Catches syntax errors that your eyes will miss at 4 PM on a Friday.

3. Check the Environment Variables

This is the one that got me. Staging and production look the same, but the environment variables are different. Database URLs, API keys, feature flags — any of these being wrong can cause silent failures that are hard to trace.

I keep a checklist of environment variables that differ between environments and verify each one. Tedious? Yes. Better than bringing production down? Also yes.

4. Test the Critical Path

I don't run the full test suite before every deploy (that's what CI is for). But I do manually test the critical user path:

• Can a user sign up?
• Can they log in?
• Can they do the main thing our product does?
• Can they pay us?

If any of those break, everything else is irrelevant.

5. Check Asset Sizes

Before shipping frontend changes, I check if any new assets are unreasonably large. An uncompressed image or an un-minified JavaScript bundle can tank your load time overnight.

Quick checks:

• No image over 200KB (unless there's a good reason)
• CSS and JS are minified
• No new fonts added accidentally

6. Verify the Rollback Plan

Can I undo this deployment quickly if something goes wrong?

For most projects, that's git revert and redeploy. But if the deployment includes database migrations, the rollback is more complex. Know this before you deploy, not during the incident.

What's Not on My List

Notice what's missing:

• Run all tests — CI handles this. If tests pass in CI, I trust them.
• Code review — already happened before merge. Not a deploy-time activity.
• Update documentation — important, but not a blocker for deployment.

The deploy checklist is specifically about "will this break production?" Not about code quality, documentation, or process. Those are important too, but they happen earlier.

The Friday Rule

I don't deploy on Friday afternoons anymore. If something breaks, I want a full workday to fix it, not a weekend of anxiety.

Monday through Thursday, during working hours. That's my deployment window. Exceptions exist, but they're rare and deliberate.

---

A checklist isn't exciting. Nobody writes blog posts about their deployment checklist and gets famous. But the purpose of a checklist isn't to be interesting — it's to catch the one thing you forgot. And it only has to save you once to be worth the two minutes it takes.