Deployment History and Status

Below the pipeline card, the Deploy screen keeps a history in two columns — Preview site on the left, Live site on the right. Each column header carries the address that column publishes to and an icon that opens it in a new tab, so you are never more than one click from the thing you are reading about. Every row in a column is one deployment: one attempt to build your site and put it in front of somebody.

How much history you get

Each column shows the last ten deployments for its site, newest first. There is no older-deployments view and no paging — once a deployment falls off the bottom of the ten it is no longer browsable in the CMS. A workspace that has never deployed to that site shows No deployments yet.

Reading a row

A collapsed row reads left to right:

• A colored state icon. Hover it for the state and the moment it was entered, written as Active at Mar 12, 2026 4:03 PM.
• The commit. The first seven characters of the git commit this deployment built. A deployment that exists before a commit has been recorded shows the literal word pending instead.
• One blue badge per reason — why this deployment happened. A row can carry several.
• The status badge — where this deployment is now.
• A second line with who started it and when.

A deployment that is still in flight tints its whole row amber and pulses the icon, so you can find the live one at a glance. If a row is the newest failed one for its column, the right-hand end carries either an amber Retry button or, when the failure is not something a re-run can fix, the gray text Content/template error — fix in content.

The status badge

Seven badges exist. The badge is derived from three separate fields — the workflow’s own status, Cloudflare’s build status and the activation status — collapsed into one label:

Those seven are evaluated in the order they appear above, and the first match wins. That precedence explains two things that otherwise look like contradictions:

• A row can read Failed even though the build itself succeeded, because a step after the build failed. Failed outranks everything except Active.
• Succeeded is transient. It means the build finished and a new version of your site was uploaded, and it turns into Active as soon as the activation is confirmed. A row that sits on Succeeded for a long time is worth expanding.

What Active really means

Exactly one row per column is marked Active: the deployment currently serving that site. When Cloudflare has not confirmed an activation yet, the newest Succeeded row is marked instead, so the column always names something.

Everything above the Active row is newer but not yet serving. Everything below it is history.

One honest edge: because Active outranks everything, a deployment that went live and then failed in a step that runs after activation still reads Active. That is the truthful answer — the version really is serving — but it means an Active row is not by itself proof that every part of the deployment finished.

The blue reason badges

The blue badges say what kind of change caused this deployment. One row often carries several: ticking five items in Pending changes produces one commit, one build and one row tagged with all five reasons. That is the point of the selector rather than a quirk of it.

Which site a change lands on is fixed by the kind of change, never chosen — preview and live are two separate sites explains why, and the final column below is the short version.

Two of these badges have no matching entry in the Pending changes selector: Search Indexes and Logo/Favicon. A logo change reaches your site as part of Settings (General), which is why the pending list does not offer it as its own line.

Managed Files and Admin Rebuild are Leed’s own housekeeping. You cannot trigger them and you do not need to; they appear so that the history stays an honest record of everything that rebuilt your site.

Expanding a row

Click a row to open it. The drawer renders, in this order:

1. Error — the build’s own output in a red block, on failed rows only.
2. The state and its timestamp, as Failed at Mar 12, 2026 4:03 PM.
3. Pages published — every page in this deployment, each linked back into the page editor.
4. Pages deleted — the pages this deployment removed, as plain text, because there is no longer a page to open.
5. No page-level changes in this deployment. — the fallback, shown when a deployment changed only settings, menus or templates and did not fail.

A failed row opens on its error instead:

A red row is worth its own page: what to do when a deployment fails covers reading that error block and deciding between fixing and retrying.

Live refresh

While anything is in flight, the screen re-fetches itself every five seconds and then stops. You never need to reload the page to watch a build. Each column header also carries a refresh control if you want to force it.

One consequence worth knowing: polling deliberately continues through the short window where the badge already reads Failed but the underlying record has not finished settling. That is why the Retry button can appear a beat after the badge does. It is the screen waiting for the two to agree, not flakiness.

When a column fails to load

The three pieces of this screen load independently, and each can fail on its own. When one does, a red banner appears above the history naming which one it was — Deployments, Scheduled or Pending Changes — with the HTTP status in brackets and the underlying message beside it, like Deployments failed to load (503).

Quote that banner verbatim in a support request. It says which of the three requests failed, which is the first thing anyone looking at it will want to know, and it is the same vocabulary used in common error messages.

A few rows in this history come from outside the CMS entirely. A row with no person on it and a Pages badge is a scheduled publish doing its job, and a Developer CLI row is somebody’s leed site push, not anything anyone did in the CMS.