Run a Dry Run First, Then Hit Confirm: Make It Muscle Memory

Let’s start with a real-world scenario: A friend working in DevOps ran a "clean up expired logs" script at 8 AM one morning. The script itself was fine; the mistake was that he overlooked a path variable, writing /data instead of /data/tmp. Twenty minutes later, the entire data directory was wiped. If he had run it with --dry-run first, the terminal would have printed a list of directories slated for deletion—he would have spotted the error immediately.

The One-Sentence Rule

For any operation where undoing is costly, run a preview/dry run first to confirm exactly what will be affected, then execute the real version.

A dry run isn’t testing; it’s the "final brake before hitting the confirm button."

Specific Use Cases

1. Batch changes to files and databases. Renaming 500 files at once, bulk-updating 2,000 records, or migrating directory structures. Correct approach: Run with --dry-run or explain first, save the "list of objects to be changed" to a file, manually spot-check 10 items, and only proceed if the counts match.

2. Changing configurations. Nginx reverse proxies, systemd services, crontabs, SSH configs, CI pipelines. Correct approach: Validate first (nginx -t, unit test dry runs, cron trial runs), and take a look at what the current live configuration looks like before deciding on the minimal scope of changes.

3. First-time deployment to production. Launching a new domain, enabling a new format site-wide, or pushing a new template to all readers. Correct approach: Send yourself a draft link and walk through the entire flow—view pages, click links, check response headers—before rolling it out to everyone.

4. Letting AI or scripts touch real assets for the first time. The first time you let an automated tool delete files, send emails, or change schedules. Correct approach: Have it output "what I plan to do," you confirm the list, and only then grant execution permissions.

When You Don’t Need a Dry Run

• Small changes reversible within three seconds: Fixing a typo, renaming a file, recalling a message just sent. Doing a dry run for these only slows you down.
• No preview mechanism available, and none can be created: Some one-off operations lack a dry-run switch. In these cases, substitute with "backup + small steps": export first, test on a single record, then roll out in batches.
• You are already executing a rollback plan: A rollback is inherently "doing the opposite," so doing a dry run is paradoxical. Just execute it and monitor the status closely.

Pre-Execution Checklist

• Can I state in one sentence what this operation "will change"? (If not, you’re not ready.)
• The dry run output has been saved, not just scrolled past on the screen.
• I’ve spot-checked the first few lines, the last few lines, and the total count of the diff, rather than just glancing at it.
• The rollback method is currently available (commands are still in the terminal, backups are on disk), not just "I remember how to roll back."
• If the first dry run didn’t match expectations → Stop and fix it, then run it again. Don’t guess.

Common Pitfalls

Pitfall 1: The dry run environment differs from the real execution environment. Different permissions (you have them during preview, but the execution account doesn’t), different working directories, different time zones, different network states. The same command might "change 3 files" in preview but "change 30" in reality. Countermeasure: Run the dry run with the same identity and directory as the formal execution.

Pitfall 2: Treating "dry run passed" as "guaranteed success." A preview can’t account for concurrency, timing issues, or external API timeouts. A dry run only ensures "what you intend to change is indeed what you want to change"; it doesn’t guarantee the execution process will be accident-free. For critical failures, you need separate notification mechanisms.

Pitfall 3: Overuse. Requiring estimation, rehearsal, and approval for every single word change will bog down your workflow. There’s only one criterion: If this change goes wrong, how many minutes will it take to recover? If it’s more than 10 minutes, it’s worth a dry run; if not, just do it and ensure you have a clear undo path.

Pitfall 4: "Glancing at the output" isn’t verification. Human eyes are unreliable when scanning long lists, especially regarding numbers and units (3 files vs. 3,000 files). Save the output to a file, use wc -l to count the total, and use head/tail to check a few lines at the beginning and end. That counts as having checked it.

Wrapping Up

The value of a dry run isn’t technical; it’s about turning the "last 10 seconds before hitting confirm" from impulse into verification. Once you make it a habit, you’ll find that it doesn’t necessarily prevent "major disasters," but rather those silly mistakes that make you think afterward, "I just needed to take one more look."