Scheduling and Automatic Publishing

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 under it the page titles run on one line, separated by commas, each linking straight to that page so you can check what is about to go out. A slot holding dozens of pages stays compact rather than pushing the rest of the card off the screen. 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.

What happens when the slot arrives

A job inside Leed runs every minute, for every workspace. Each run does the same four things:

1. It collects every page whose scheduled time falls within roughly the next three minutes.
2. It groups them by workspace.
3. For each workspace it commits that whole cohort as one git commit and creates one deployment, badged Pages.
4. 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.

If the run that publishes a cohort errors or ends without publishing, the next tick launches it again, up to three attempts in all, so a passing hiccup does not leave pages stuck in Scheduled. A page that has been published before and is then scheduled again publishes at its new time like any other.

A retry picks up where the failed attempt stopped rather than starting over. Once a cohort has been committed to your site repository it is never committed again, so however many attempts a run takes, a release still ends as one commit, one deployment and one build.

A retry also finishes only what is still due. A page whose time you have moved later waits for its new slot instead of going out early with the rest. A page someone has taken back into editing in the meantime — unscheduled, or revised after an earlier attempt already put it live — is left alone, so an unreviewed draft is never published by a retry. And a page that has gone live since in a newer publish is not rolled back to the older version.

One publish job at a time

Each workspace has at most one publish job running at once. If the job an earlier tick started is still committing and building when the next tick comes round, that tick leaves your workspace alone rather than starting a second job beside it. Pages that came due in the meantime are not lost: they go out together in the next job, launched on the first tick after the running one finishes. Pages waiting to come off the site after a deletion wait the same way.

That is what keeps a large release to a single job instead of several overlapping ones publishing the same pages. The trade is timing: a page whose slot arrives while a long job is still running goes live once that job is done, which can be a few minutes after its slot.

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.

A release of several hundred pages in one slot — a whole documentation set, say — still goes out as a single job: one commit, one deployment and one build, with every page published. The work after the commit is done in small pieces, so a large release does not run out of time partway through and leave your site unbuilt.

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 jobs instead of all at once. Nothing is dropped: anything the current job does not take stays scheduled and goes out in the next one, once the current job has finished. A very large release is slower, not broken.

Scheduling a whole set or a release at once

Setting dates one page at a time is fine for a post. For a documentation set or a release, three routes put many pages into one slot in a single step, and each previews the outcome page by page before anything is scheduled:

• Schedule Set Publish, a button on a documentation set’s toolbar in the left navigation, schedules every in-revision page in that set for the time you pick.
• schedule_pages_by_id over MCP does the same for a list of page ids.
• schedule_pages_by_source_id over MCP, or the matching API route, schedules every page whose source id matches one of a list of commits. A page carries the source id of the commit it was last edited against, so a release pipeline can schedule exactly the pages its release changed. The pipeline signs in with its own OIDC identity, through a trust registered under Settings → CI Trust that limits it to one repository, chosen page types and an editorial ceiling — the least-reviewed status it is allowed to publish. Scheduling by source id is a Growth plan feature; its dry run works on every plan.

The slot does not have to be in the future. Pick a time that has already passed and the pages publish on the next run of the per-minute job, carrying the date you gave them — the way to publish now while back-dating a page to when its content is really from.

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.