Can you safely reverse your last deployment?

Every site has a rollback story. Most of them are told after the fact: “we could have gone back if we had known which version”, “the old theme had been deleted”, “the database had moved on”. This week: take the last deployment you made — however small — and prove you can reverse it. Not in principle. With the steps written down, rehearsed somewhere safe, and the data question answered.

The problem

“We can roll back” is one of the most common untested claims in web operations. It rests on a chain: knowing what the last deploy changed, knowing exactly what was there before, having that version still available, having a way to put it back, and knowing what happens to anything created since. Any link can be missing, and the only time most people find out is during an incident, when the person who knows is unavailable and the notes say “roll back”.

Prerequisites

• A site you deploy — through Git and a pipeline, a hosted platform's publish button, a Shopify theme, a WordPress update, anything with a “before” and an “after”.
• Access to the deployment history: commits, releases, theme library, plugin versions, or the platform's activity log.
• A non-production copy (staging, a preview deploy, a duplicate unpublished theme, a local environment) — or a quiet window and a very small deploy.

Scope

The last deployment only. The exercise is not to build a rollback system; it is to find out whether one exists for one real change. Rehearse on a non-production copy wherever possible. If the only way to rehearse is on production — a hosted platform with a one-click rollback and no staging — do it in a quiet window with a change small enough that a minute of the previous version costs nothing, and undo it immediately.

Safe inspection workflow

1. Name the deploy. What changed, when, and who did it. A commit hash, a release tag, a theme name and time, a plugin version pair (3.4.1 → 3.4.2). If you cannot name it, that is the first finding.
2. Name the previous version. The exact thing you would return to. Check it still exists: the commit is on the remote, the previous theme is still in the theme library, the previous plugin version is downloadable, the platform's history still lists it. Retention windows expire.
3. Write the steps as commands or clicks. git revert <hash> && git push and what the pipeline then does; “Online Store → Themes → previous theme → Publish”; the platform's “Rollback to this deployment” button; the plugin's version-rollback tool. Include how long it takes and how you would know it worked (the URL to fetch, the thing to look for).
4. Answer the data question. What has been created since the deploy — orders, form submissions, content edits, settings changes — and does the rollback touch it? Code rollbacks usually leave data alone; database restores do not; theme publishes on Shopify keep settings per theme; content-platform rollbacks vary. Write the answer down, including “unknown”.
5. Rehearse. On the non-production copy, perform the rollback and confirm the “before” version is what appears. Then roll forward again. If rehearsing on production in a quiet window, keep it under a minute and fetch the page before and after.
6. Hand it to someone. Read the notes as a stranger: could a colleague execute them at 2 a.m. without asking you anything? If a step needs a password or a token, write down where it lives — never the value.

Copyable prompt

For a Git-based project with Claude Code. It reconstructs the deploy from the repository and drafts the rollback notes; it does not deploy, revert, or push.

Read-only. Do not run git revert, reset, checkout, push, or any deploy command. Do not edit files.

1. Identify the most recent deployment from this repository: the latest tag or release, the last commit on the deploy branch, or the last pipeline run recorded in the repository (workflow files, CHANGELOG, release notes). State which of these you used and how confident you are.
2. Summarise what that deployment changed (files, and in one line each, what the change does).
3. Identify the exact previous deployable version (tag/commit) and confirm it exists on the remote from the information available to you.
4. Draft rollback notes for a colleague: the exact commands, in order, that would return production to the previous version through the same pipeline; how long each step takes; the URL(s) to fetch afterwards and what to look for.
5. Answer the data question: from the code and migrations, does rolling back this deployment touch stored data (schema migrations, content, settings)? If you cannot tell, say so.
6. List what you could not verify from the repository alone (platform-side history, secrets, DNS).

Example evidence

An example written for this page.

Weekly Fix #3 — rollback rehearsal — 2026-10-01
Deploy: 2026-09-29 16:40, commit 8f3c2a1 "Add size guide to product page" (theme, Shopify)
Previous: theme "Live 2026-09-22" — still in theme library, unpublished ✔
Steps: Online Store → Themes → "Live 2026-09-22" → Publish (≈10 s). Verify: fetch /products/x, size guide absent, add-to-cart works.
Data: theme settings live per theme; orders and customers untouched. Size-guide metafield content stays (harmless).
Rehearsal: duplicated "Live 2026-09-22" → published in quiet window 07:02 → fetched product page: previous version ✔ → republished current 07:03.
Handover: notes in /ops/rollback.md; the receptionist executed step 1 from the notes in a dry run without help.

Completion criteria

• The last deployment is identified: what changed, when, and the exact previous version.
• The rollback steps are written as commands or clicks.
• The rollback was rehearsed on a non-production copy, or performed and undone in a quiet window.
• The data question is answered — including “unknown” if that is the answer.
• Someone other than you could execute it from the notes alone.

Common mistakes

• Assuming the previous version is still there. Theme libraries get tidied, retention windows expire, branches get deleted.
• Rolling back the database with the code. A backup restore that returns yesterday's database also returns yesterday's orders.
• Notes that say “redeploy the previous version”. That is the goal, not a step.
• Rehearsing nothing because “it's obvious”. The rehearsal finds the missing permission, the expired token, the button that moved.
• Writing a secret into the notes. Where it lives, never what it is.

Go further

• The Launch Readiness Lab has a release summary whose “rollback: previous version available” line is worth reading twice.
• Deploying with GitHub Actions and Cloudflare has a rollback section and a regression-plan generator; the maintenance checklist keeps rollback readiness on the monthly list.