Rollback: what happens when a change is wrong

A change goes live in the afternoon. By evening a customer tells you the pricing page looks wrong on their phone. The question that matters is what happens next, and how long it takes. This post explains what happens on a site we run, what rollback and revert mean, and exactly what to send us so the fix is quick. It ends with a comparison to the other common way of changing a website: editing it on the live server.

Every deployment is kept

A site we build lives in a source repository, and the live site is built from that source. Our hosting is Cloudflare Pages, and its Git integration means that “Cloudflare will automatically deploy your code every time you push a change to a branch”^[1]. A push sends a set of changes to the repository. Each push produces a deployment: a complete copy of the site as it stood at that moment.

The important word is copy. A new deployment does not overwrite the old one. Cloudflare’s own rollback documentation states that “any production deployment that has been successfully built is a valid rollback target”^[2]. In plain terms, the list of past deployments is every version of your site that has been live, and any of them can be put back.

This is deliberate. Part of what we deliver at the Live stage is “hosting, the deployment pipeline and uptime monitoring, run by us”, and keeping every deployment is why the pipeline is set up the way it is.

Most mistakes never reach the live site

Before a change is live at all, it is built as a preview. Cloudflare explains that “preview deployments allow you to preview new versions of your project without deploying it to production”^[3]. By default, “Pages will automatically deploy any and every commit to a preview branch”^[4], and each preview gets its own address, because “each new branch you create will receive a new, randomly-generated hash in front of your pages.dev subdomain”^[3].

The preview is separate from your site. “Any custom domains, as well as your user-example.pages.dev site, will not be affected by preview deployments”^[3]. These are the staged previews you see during the Build stage, and the same mechanism runs for content changes after launch. Most wrong changes are caught here, where no customer can see them.

Rolling back is one action

Sometimes a problem only shows up live. This is what a rollback is for. In Cloudflare’s words, “rollbacks allow you to instantly revert your project to a previous production deployment”^[2].

Open the list of deployments, choose the one you want, and confirm. “When confirmed, your project’s production deployment will change instantly”^[2]. Nothing is rebuilt, because the earlier copy already exists. The rollback only changes which copy is served on your domain.

Two details are worth knowing. First, a rollback is not a one-way door: “when your project has rolled back to a previous deployment, you may still rollback to deployments that are newer than your current version”^[2]. If we roll back too far, we can roll forward again. Second, “preview deployments are not valid rollback targets”^[2]. A rollback always returns you to something that was actually live before, never to an untested draft.

Rollback is not the same as fixing the source

A rollback changes what visitors see. It does not change the source. The wrong change is still in the repository, and the next push would build it again and put it back. So a rollback is the first step, taken to stop customers seeing the problem. A second step follows in the source.

That second step is a revert. Git, the tool that keeps the source history, describes the command this way: “given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them”^[5]. A commit is one recorded change. A revert is a new commit that undoes an earlier one.

Git offers other ways to go backwards, and the difference matters. Its documentation is explicit: “git-revert is about making a new commit that reverts the changes made by other commits”, whereas git-reset “is about updating your branch, moving the tip in order to add or remove commits from the branch. This operation changes the commit history”^[6]. We use revert. The history keeps both the mistake and the fix, so anyone reading it later can see what happened.

When a change arrived as a pull request, which is a proposed set of changes reviewed before it is merged, the undo is a button. GitHub explains that “reverting a merged pull request creates a new pull request that reverts the original merge commit”^[7]. That new pull request gets the same preview and merge as any other change, and the pipeline deploys the result. The source and the live site agree again.

What happens, and what you see

Situation	What we do	How long it takes	What you see
A change looks wrong on its preview address	Fix it before merging. Nothing has reached your domain.	Depends on the fix	Nothing changes on your site
A change is live and looks wrong	Roll back to the previous production deployment	Cloudflare states the production deployment changes “instantly”[2]	The previous version of the page
The rollback is in place	Revert the change in the source; the pipeline builds and deploys the result	One automatic build and deployment	No visible change; the site now matches its source
The change was right but had one error	Fix the error in the source and push	One automatic build and deployment	The corrected version of the change

The only time claim in that table is the one Cloudflare makes about rollbacks. A build’s length depends on the site, and we would rather you read it from the deployment log than from a blog post.

The other way: editing the live server

Many websites are changed by editing files on the server that is serving them. WordPress makes this easy. Its Theme File Editor “allows you to view or change any code kept in a Theme Template or Stylesheet files”^[8], from inside the admin screen, on the live site.

WordPress’s own documentation for that screen carries a warning worth reading in full: “Be very careful editing PHP files of your current theme. The editor does not make backup copies. If you introduce an error that crashes your site, you cannot use the editor to fix the problem. In such a case, use FTP to either upload a functional backup of the problem file or change the folder name of the current theme so WordPress is forced to use a different theme”^[8]. It adds that “changing files in this manner is not recommended. If you update the theme all of your changes will be lost”^[8].

Mistakes happen on every platform. The difference is that on a live-edited site the previous version stops existing the moment you press Update File. There is nothing to roll back to unless someone took a backup first.

WordPress’s backup guidance is clear that this is your job. A site “consists of” the core installation, plugins, themes, images and files, code files and static pages, plus a separate database^[9], and “if your database gets erased or corrupted, you stand to lose everything you have written”^[9]. On hosting: “Most hosts back up the entire server, including your site, but it takes time to request a copy of your site from their backups, and a speedy recovery is critical. You need to learn how to back up your own site files and restore them”^[9]. The recommended frequency is that “for smaller websites with fewer posts, backups should be made once a week”^[9].

A weekly backup returns you to last week. A deployment pipeline returns you to the moment before the change. To be fair, a WordPress site can be run from source control with a pipeline, and some are. The point is what the platform does by default.

What to send us when something looks wrong

The Live stage of our process is simple: you “send content changes when you need them” and we run the pipeline. The same channel is for problems. Five things let us find the fault on the first look.

• The address. The full URL of the page, copied from the browser, not “the services page”.
• The device and browser. Phone or desktop, and which browser. A layout fault on a small screen may be invisible on a large one.
• The time. When you saw it, in Perth time. We can match this against the deployment list and the uptime monitor.
• A screenshot. What the screen showed. A photo of the screen is fine if a screenshot is awkward.
• What changed. What you expected to see, what you see instead, and whether anything was sent to us for change recently.

With those five we can tell whether the fault is a change we made, a change in the browser, or something in the content. If it is ours, the rollback happens first and the questions come afterwards.

What you can do next

If you are comparing quotes, ask each vendor one question: if this afternoon’s change is wrong, what do you press, and what was there before? For our answer on your own site, the brief builder takes three minutes and comes back with a fixed price. For the rest of what we build with, read what React is and how islands keep it small, and the measured figures on the home page.

Reference list

All sources accessed 18 June 2026.

1. Cloudflare (n.d.) Git integration. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/git-integration/
2. Cloudflare (n.d.) Rollbacks. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/rollbacks/
3. Cloudflare (n.d.) Preview deployments. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/preview-deployments/
4. Cloudflare (n.d.) Branch build controls. Cloudflare Pages documentation. https://developers.cloudflare.com/pages/configuration/branch-build-controls/
5. Git (n.d.) git-revert: Revert some existing commits. Git reference documentation. https://git-scm.com/docs/git-revert
6. Git (n.d.) git: Reset, restore and revert. Git reference documentation. https://git-scm.com/docs/git
7. GitHub (n.d.) Reverting a pull request. GitHub Docs. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request
8. WordPress.org (2023) Appearance Theme File Editor Screen. WordPress Documentation. https://wordpress.org/documentation/article/appearance-theme-file-editor-screen/
9. WordPress.org (n.d.) Backup. WordPress Advanced Administration Handbook. https://developer.wordpress.org/advanced-administration/security/backup/