Self-healing background runs

A background run can do more than report. It can guard a risky live change and undo it if the change does not take.

This is the week 07 update to Mastering Claude Code: a short walkthrough of what changed in the guide during the week of the twenty-ninth of June.

The headline

A background run doesn’t have to just report. It can guard. The Async chapter already covered background jobs that notify you when they finish. This week adds the pattern that makes them safe for outward-facing work: pair a risky live change (a DNS flip, a deploy cutover, repointing a live service) with a background watcher that checks for the outcome you wanted, and reverts automatically if that outcome doesn’t show up by a deadline. Chapter 7 gains a new section called self-healing background runs.

Why it was needed

The gap was between “I can run this in the background” and “I can trust this change to the live system without babysitting it.” A cutover you’d normally sit and watch, because the failure mode is a customer-facing service left down, is exactly the kind of thing you want to hand off, but only if failure can’t be silent. The self-healing watcher closes that gap. It polls for the success signal, and if the deadline passes without it, the watcher runs the rollback itself and tells you what it did. You hear about it either way, live on the new host or reverted and here’s why, without standing watch.

What prompted writing it down was a run of live cutovers where the first attempt flipped a production hostname before the new host was ready and took the site down, and then a hurried manual rollback left a stale binding behind that kept it down. The fix wasn’t to be more careful. It was to encode the caution: stage on a preview address, verify, cut over, and let a watcher own the revert. Every cutover after that was fire-and-forget, with a floor under it.

What changed in the guide

In Chapter 7, on async, there’s a short new section after background runs. It sets out the shape (apply the change, poll for a success signal that holds, roll back automatically on the deadline) and the two disciplines that make it trustworthy.

The first is a consistent success signal. Require two good readings in a row, not a single lucky one near the deadline. A passing blip shouldn’t be allowed to declare a false victory.

The second is a complete rollback. Restoring the DNS record isn’t enough if the cutover also registered the hostname somewhere that now swallows its traffic. The rollback has to unwind every side effect of the change, or the safe path is still broken.

No other chapters were touched this week.

The cards