Give a page a publish date in the future and you are done: Leed commits it, builds your whole site and uploads the result before the moment you chose, then holds the finished build back until that exact minute. The page appears on the minute, not some unpredictable number of minutes after it. You pick the date and time in the editor — setting a publish date covers that half — and this page is about everything that happens once you close the page and walk away.
The Scheduled for publishing list
The Deploy screen (/deployments) shows what is queued. It lives at the bottom of the full-width Live site card, under the heading Scheduled for publishing.
The list groups pages into one block per exact time slot, earliest first. Each block is headed with the slot itself, written like Mar 14, 2026 9:00 AM, and every page title under it links straight to that page so you can check what is about to go out. Two pages scheduled for 9:00 and 9:01 are two separate blocks, not one.
If nothing is scheduled, the heading is not rendered at all — there is no empty state to read. An absent list means nothing is queued, not that something is broken.
How far ahead it looks
The list looks 365 days ahead. A page scheduled further out than that is real and will publish exactly as you set it; it simply is not listed yet, and appears once the slot comes inside the one-year window.
| The list shows | The list does not show |
|---|---|
| Pages whose latest revision is scheduled, up to a year ahead | Pages scheduled more than a year out |
| One block per exact time slot, earliest first | Any ordering of pages inside a single slot |
| Every page’s title, linked to the page | Pages you have deleted that are still waiting to come off the site |
| — | Settings, menus, labels or anything else in Pending changes |
What happens when the slot arrives
A job inside Leed runs every minute, for every workspace. Each run does the same four things:
- It collects every page whose scheduled time falls within roughly the next three minutes.
- It groups them by workspace.
- For each workspace it commits that whole cohort as one git commit and creates one deployment, badged Pages.
- The build runs, renders your entire site and uploads a new version of it — which is not yet serving anyone.
The deployment then waits, durably, until the exact minute you chose. Only then does Leed activate the uploaded version at 100% of traffic.
sequenceDiagram
autonumber
participant J as Leed, every minute
participant G as Your site repository
participant B as Cloudflare Builds
participant W as Your live site
Note over J: About three minutes before the slot
J->>G: Commit the whole cohort as one commit
J->>J: Create one deployment row, badged Pages
J->>B: Trigger a build of that commit
B->>B: Render every page of the site
B->>W: Upload a new version (not yet serving)
B-->>J: Report the finished version back
Note over J,W: The deployment waits for the minute you chose
Note over J,W: The minute arrives
J->>W: Activate the version at 100% of traffic
W-->>J: Visitors now see the page
Treat “about three minutes” as an approximation rather than a contract — it is a default Leed can adjust, and it exists to absorb build time rather than to be planned around.
Several pages at the same minute
Pages that share a slot publish together, as one commit, one build and one row in the history. That is the intended way to release a batch: a set of documentation pages, a launch, a whole month of posts. It is also much cheaper than releasing them one at a time, because every deployment rebuilds your entire site regardless of how many pages changed.
There is a ceiling on how many pages one run will take, and it is high enough that most workspaces will never meet it. An unusually large cohort — thousands of pages at the same minute — publishes in batches across consecutive minutes instead of all at once. Nothing is dropped: anything the current run does not take stays scheduled and is picked up on the next tick. A very large release is slower, not broken.
Deleting a published page is also a scheduled job
The same per-minute job collects one other thing: pages you have deleted that are still live on your site. It publishes their removal as an ordinary deployment, exactly as it publishes a scheduled page.
That is why a pending deletion never shows up in the Scheduled list even though it behaves like one. The list is deliberately narrower than the job that drives it: it shows only pages whose latest revision is scheduled, and never the deleted set. If you have deleted a live page and are waiting for it to disappear, watch the history rather than the Scheduled list — deleting and unpublishing a page explains what the deletion itself does.
Who initiated it
A scheduled deployment has no person attached to it. Its history row shows the initiator as System, and that is correct rather than a gap in the record — nobody clicked anything at 9:00 AM. Publishing the same page by hand from the editor puts your name on the row instead. Reading a deployment row walks through the rest of what that line tells you.
Time zones and near-future slots
The Scheduled list renders each slot in your own browser’s time zone. The slot itself is a fixed moment, so a colleague in another country sees the same publish time written differently — worth remembering before anyone concludes a page is scheduled for the wrong hour.
The same slots appear on the Plan calendar as Deploy entries alongside your campaign deliverables, which is the better view when you are looking at a week rather than at one page.
Building ahead only helps if the build succeeds. A scheduled build that fails leaves the previous version of your site serving, so the old page stays live and the new one simply does not appear — what a failure looks like, and what to do about it.