The Dry-Run Checklist to Run Before Letting Claude Code Deploy to Production

Late on a Friday, I told Claude Code, “Push the fix for this article to production.” What came back was a single line, “Published,” and a green check mark. I closed the laptop and went home. The next morning, the homepage of my site was a blank white page.

The cause was embarrassing. Nobody had opened the preview. Claude Code had only looked at the log where the build passed and decided it was a “success.” But the live page was loading a different article’s template, and the content was empty. Because the server still returned HTTP 200, the deploy looked, mechanically, like a clean publish.

That night taught me that fast and safe are two different things. Hand off a whole deploy and it looks like it finished in a second. But if there’s no record of what you actually verified, then when it falls over you have no idea what to roll back. So today I’m writing down the fix I use: a “dry run” that collects evidence before you ever hand over production access.

Key takeaways

• Most accidents when Claude Code deploys come from skipping the checks that happen before it touches production.
• Before granting production access, dry-run five things: the build, the diff, the preview URL, the rollback owner, and the areas you did not touch.
• Separating “checks a machine can judge” from “judgments a human has to make with their eyes” cuts down the 2 a.m. incidents.
• I’ve included a copy-paste prompt template and a script that machine-checks the dry-run result.
• You don’t need a perfect operating policy from day one. Try it on one fix, and add whatever tripped you up to the checklist next time.

Deploy accidents come from missing checks, not missing intelligence

Claude Code is smart. But being smart and being able to act safely in production are two separate things.

It’s like the student who aces every exam and then breaks the register on their first shift at a part-time job. It isn’t a capability problem; it’s a scaffolding problem. For deploys, the scaffolding is “what you verify before touching production.”

Static-site deploys are especially good at failing quietly. The build passes, the server returns HTTP 200, and on the surface everything looks fine. The content can be empty, or swapped for a different page entirely, and if all you’re watching is the status code, you’ll never notice. That’s why you can’t ask “did the code run?” You have to ask “is the correct page showing correctly?” and a human has to look at it once.

The five-step dry run before you touch production

This is the entire procedure I use right now. The order matters, so I’ve laid it out top to bottom.

1. Pass the build locally first. If this fails, the production conversation is over early. You separate “is it the code?” from “is it the environment?” before you ever touch prod.
2. Read the diff. Check with your own eyes that no secrets (API keys, tokens) or billing-related changes slipped in.
3. Open the preview URL. Confirm on the actual screen that the heading (h1), the canonical URL, and the destination of the signup button are what you expected.
4. Decide the rollback owner and the rollback method. When it fails, who rolls it back, and with which command? If you don’t decide this first, you’ll freeze the moment something goes wrong.
5. Ask for production access only after the evidence is in. Only once steps 1 through 4 have produced results do you ask Claude Code to deploy to production.

Just following this order makes the “blank homepage” accident from the intro almost impossible, because step 3 forces you to open the preview every time.

What you delegate to the AI, and what a human decides

This isn’t “hand everything to the AI” or “go back to doing it all by hand.” You split the roles. The table below is the line I draw in my own work.

Situation	What Claude Code handles	Evidence the human reviews
Publishing an article	Run the dist build and the public-URL auto-check first	Build result, diff, URL
Changing the signup button	Reconcile the link target and consultation path on the preview	Build result, diff, URL
Fixing a Worker	Touch no environment variables, emit dry-run logs only	Build result, diff, URL

The point is this split: let the AI do the reading, the laying-out, and the machine checks, and have a human approve any operation that makes an irreversible change in production. Deletes, writes to the production database, billing, and force pushes all start out tilted toward “ask a human.” You only promote an operation to automatic later, once you’ve confirmed it’s safe.

If you want to draw the permission line in more detail, the permission settings guide and the pre-deploy permission audit are good references.

A copy-paste prompt template

The trick is to not just throw the request over the wall, but to spell out “don’t push to production yet.” You can paste the template below as-is.

Turn this change into a "dry-run checklist" to run before deploying to production.
Return the following items as a table:
- Build result (success / failure with the key log lines)
- Diff risk (does it include secrets, billing, or deletions?)
- Preview URL
- Rollback owner and rollback command
- Areas left untouched
- Retry conditions
Do NOT run the production deploy yet.
Wait until I have confirmed the checks.

The last two lines are what does the work. Writing “don’t run it yet” and “wait until I confirm” prevents the accident where Claude Code tries to be helpful and publishes on its own. There’s more on writing prompts that fail safe in the advanced prompt design guide.

A verification script you can paste and run

When you judge the result with a machine instead of a “gut feeling,” you miss less. The script below takes the dry-run result object and returns a boolean for whether you’re clear to ask for production access. If you have Node.js, it runs as-is.

// The dry-run result. Put your actual verification here.
const deployCheck = {
  build: "passed",              // did the local build pass?
  diffReviewed: true,           // did you read the diff with your eyes?
  previewUrl: "https://example.pages.dev", // preview URL
  rollbackOwner: "Masa",        // who rolls it back
  changedAreas: ["content", "cta-copy"],   // what you touched
};

// The gatekeeper that decides if you're clear to ask for production access
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // the build passed
    check.diffReviewed &&                // you reviewed the diff
    /^https:\/\//.test(check.previewUrl) && // the preview URL exists over https
    check.rollbackOwner.length > 0 &&    // a rollback owner is assigned
    !check.changedAreas.includes("secrets") // you didn't touch a secret area
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// Until every false field is filled, don't ask for a production deploy

The value of this code is the moment changedAreas contains "secrets", it returns false. While you’ve accidentally touched secrets, you can never advance to the production-access request. Even if a busy human overlooks it, the gatekeeper stops you.

Three places it actually paid off

First, publishing articles. With just “go publish the blog,” it runs all the way to publish the moment the build passes. Slip in a dry run and you open the public URL to check the heading matches the content first, which stops the blank-page accident from the intro.

Second, swapping a signup button. Mistype the link target by a single character and your hard-won funnel drops into a 404. After I added a step to actually press the button on the preview and confirm where it goes, broken links dropped to zero.

Third, fixing a Cloudflare Worker. Here, deleting a single environment variable takes production down. So in the dry run I don’t let it touch environment variables; it only emits logs. The Worker-specific gotchas are collected in the Cloudflare Workers integration article.

Common pitfalls and how to fix them

Three mistakes I actually made, and how I fixed them.

Pitfall 1: running a production command before the build. Fire off wrangler deploy straight away and, when it fails, you can’t tell whether it’s the code or the environment. The fix is simple: always pass the local build first. Reordering one step makes root-cause analysis dramatically faster.

Pitfall 2: not deciding the rollback owner. Start discussing “who rolls it back?” after the failure, and those few minutes of discussion are minutes your traffic is taking the hit. The fix is to write down the rollback owner and the rollback command during the dry-run stage. Even just keeping a note of previousDeployId makes recovery calmer.

Pitfall 3: trusting the status code without opening the preview. HTTP 200 only means “the server returned something,” not “the correct page rendered.” The fix is to always open the preview URL in a browser once and look at the heading, the canonical URL, and the hero image with your own eyes. That was the only way I caught the blank page from the intro.

Keep the evidence as a “note you’ll reuse next time”

If you don’t delete what you verified in the dry run, but instead pull it into a short note, the next round of work gets much faster.

This much is enough: the original request you sent, the range Claude Code read, the range it didn’t touch, the verification commands you ran, the public URL or screenshots, and the points where you weren’t sure. You don’t need a long meeting transcript. As long as you can later trace “why did I make this call?”, the note has done its job.

What helps most is writing the “decision fork” in one line. For example: “the preview URL is correct, but the rollback owner is unset, so production is still on hold.” The next time you do the same work, you or anyone else can reproduce the same checks. The same thinking applies to automation beyond deploys, so reading this alongside the Claude Code intro for non-engineers helps you get a feel for how to delegate.

FAQ

Q. Isn’t a dry run just more work, in the end? It feels that way at first. But once an accident happens, recovery and root-cause hunting can eat hours. A dry run takes minutes. I keep doing it because it’s insurance that pays for itself.

Q. If the local build passes, can I skip the preview? No. Even when the build passes, template swaps and empty pages still happen. HTTP 200 and “the correct page” are different things, so you can’t skip the visual check.

Q. Is there any point deciding a rollback owner if it’s just me? Yes. Even solo, writing down “if it fails, I roll back with this command” beforehand means you won’t hesitate when it actually breaks. Deciding it is the procedure.

Q. When Claude Code says “Published,” can I trust it? Look at the dry-run evidence rather than the reply itself. Judge by whether the build, diff, preview, and rollback owner are all in place. Words are vibes; evidence is fact.

Q. Do I really need all this for a small site? Think in terms of “can I roll it back?” rather than scale. Small or not, if production goes down it’s a problem. Start by adding just the one step of opening the preview, and you’ll feel the difference.

What I confirmed after trying it

After the blank-page accident in the intro, I built this dry-run procedure into how I run my own blog.

I confirmed three things. First, once I made opening the preview URL a hard rule, empty pages from template swaps dropped to zero. Second, once I started running the verification script above before publishing, changes that touched a secret area stopped at ready: false and never advanced to the production-access request. Third, once I started noting the rollback owner and rollback command every time, even the close calls could be reverted to the previous state in a few minutes.

Rather than handing everything to a smart AI and praying, build the scaffolding that keeps you from getting hurt when you trip. It looks like the long way around, but it turns out to be the fastest, that’s my honest read right now. Start with the single step of opening the preview, and add a gatekeeper to your own deploys.

If you want to nail down where to draw the production-deploy line and the review process across a team, we can turn it into a procedure together in training and consultation. For the official operating baseline, see the official Anthropic Claude Code documentation.