Publish history
Read every publish a site has had, see why one failed, and go back to an earlier version.
On this page
Every publish is recorded, whether it worked or not. The record lives in the Publishes tab, and it is the first place to look when someone asks what went live and when.
Open the Publishes tab
Open the project, click More in the tab strip, then Publishes. The address is /dashboard/projects/<project>/publishes.
Before your first publish the tab shows an empty state reading No publishes, with the line "Sites appear here once you publish one." If the list cannot be loaded it reads Could not load publishes, with "Refresh the page to try again."
Read a row
Each row is one publish, newest first. It shows the avatar and first name of whoever pressed Publish, a version number, a coloured status dot with its label, the date and time, and how long the publish took.
A row reads like v7 by Sarah, then Published · 03 Mar, 2026 - 4:12PM · 1m 48s underneath.
A publish a deploy hook started also names the hook. When something called its URL, no member pressed anything, so the row reads like v8 by GitHub Actions with a lightning icon. When a member started it through the hook, with Trigger now, from chat or over MCP, it reads like v9 by Sarah via GitHub Actions. The name only shows while the hook still exists. Once it is deleted, or the project is transferred, a row the URL started reads by -, and one a member started names only the member.
Version numbers count from the oldest publish, so the newest row always carries the highest number. Times are shown in your own timezone. A publish still running shows In progress in place of a duration.
The list loads ten at a time and fetches the next ten as you scroll.
Statuses
| Status | What it means |
|---|---|
| Provisioning | The server for this site is being prepared |
| Deploying | Your site is being built and moved onto that server |
| Published | The publish finished and this version is what visitors see |
| Failed | The publish did not complete. The row does not say why, so read When a publish fails |
| Cancelling | You pressed Stop and the publish is winding down |
| Cancelled | The publish was stopped before it finished |
The first four stages of a publish all report as Provisioning, so a row sitting on it for a while is normal on a site's very first publish.
Watch a publish as it happens
While a publish runs, the publish popover shows live progress instead of history. Steps are grouped into three sections, Setup, Build and Deploy, and each step ticks green as it completes: provisioning the server, creating and starting the build machine, compiling the application, uploading it, creating the production server, downloading the application, waiting for it to be ready, then switching traffic.
A Stop button appears under Publish while one is running. Stopping leaves the currently live version untouched.
View in Logs at the top right of the progress list opens the Logs tab on its Publish Logs sub-tab, where the raw build output is.
When a publish fails
The popover turns the progress list into a failure panel headed Publish failed with the line "Your app build ran into an issue." and the tail of the build output underneath.
Three buttons sit below it:
- View logs opens the full output in the Logs tab.
- Copy logs copies the output to your clipboard.
- Fix with AI takes you back to chat with the build error attached to your next message, so you can ask for a fix without pasting anything.
A failed publish does not take your live site down. The previously published version keeps serving until a publish succeeds.
Going back to an earlier version
There is no rollback button in the Publishes tab. Publishing always takes your current preview, so going back is two steps: restore the preview to the state you want, then publish it.
Open More, then Backups, and use its Code tab. The address is /dashboard/projects/<project>/backups. Each entry there is a saved state of your site's code, labelled by where it came from, such as Automatic for one taken as the AI worked or Restore for one created by a previous restore (see Backups for every label), with the author, the time and a short commit reference.
Open the three dots menu on the version you want and choose Restore. Then publish.
What restoring costs you
Restoring rewrites your working files back to that version and deletes the project's entire chat transcript for everyone in the project. It cannot be undone.
You are only asked to confirm when there is something to lose. If the AI is generating, the dialog is titled "Stop AI and restore this code backup?" and the button reads Stop and restore. If messages are queued, it names how many will be thrown away unsent. With nothing queued and nothing running, the restore happens straight away with no dialog. Backups covers this in full.
Restoring does not touch the published site. Visitors keep seeing the last published version until you publish again.
Ask chat about your publishes
Chat reads this same history when you ask, for example when did my last publish fail?, and can break one publish down step by step, from preparing the build to switching traffic, to answer why was my last publish slow?. It can stop a publish that is still running too. It never restores an earlier version for you: that stays in the Backups tab.
Next
- Publish a site covers the publish itself.
- Your free web address is where a published site first appears.
- Connect a custom domain puts it on your own address.
- Deploy hooks start a publish from outside Modulify.