A rollback restores a previous deployment after a bad upload. It is faster and safer than trying to edit the broken release in place: return visitors to the known-good version first, then fix the problem locally.

When to roll back

  • The homepage is blank or returns an error after a deploy.
  • Critical images, CSS, or JavaScript disappeared.
  • A form, checkout link, or navigation change is broken.
  • You published the wrong build folder.

Safe rollback process

  1. Open the site’s Deploy history.
  2. Find the most recent release that you know was working. Use its time, label, and preview if available.
  3. Choose Roll back and wait for the confirmation.
  4. Open the live URL in a private browser window and test the page that failed.
  5. Check the site’s logs or browser console to understand the failed release before deploying again.

Do not use rollback as a substitute for diagnosis

Keep a copy of the failing ZIP and note what changed. Typical causes are a missing asset, a wrong filename case, a nested dist folder, or an unsupported server-side feature in a static site. Correct the source, rebuild the publish folder, then deploy a new release. Do not overwrite the previous good local copy.

Quick verification

curl -I https://your-site.ziphost.co/
curl -s https://your-site.ziphost.co/ | head

The first request checks status and headers; the second confirms the expected HTML is live. Repeat for an affected page or asset, not only the home page.