Scheduled publishing

Banners have always been time-boxed, but publishing a template has always meant now. A rebrand that has to land at 00:01 on the first of the month therefore meant somebody being awake for it.

A scheduled publish books the change instead. You choose the instant, Sigil publishes it.

Booking one

Schedule sits alongside Publish in both editors. You give it a date and a time, and Sigil converts that to a fixed instant.

Both editors read that time in your own browser’s time zone. There is no zone picker, unlike a banner window, because a publish is a single instant rather than a period that has to survive a daylight saving change in the middle of it. If you are booking a publish for an office in another country, convert the time yourself before you type it. The HTML editor names the zone it read underneath the field, so you can check which one that was; the designer says only that it read your own.

The same checks a publish runs apply when you book it: the rendered signature has to fit inside Outlook’s 30,000 character limit, a designer template has to validate, and plain HTML cannot be scheduled over a designer template: the HTML editor disables Schedule and Publish for one, and the API refuses it unless the request explicitly asks to convert the template. A schedule that would be rejected at midnight is rejected now instead.

There is one pending schedule per template. Booking a second from the editor replaces the first rather than queueing behind it, since the banner has already told you one is booked. If a colleague booked one after you opened the editor, your booking is refused with “A publish is already booked for this template. Cancel it or replace it.” The banner then appears, and booking again replaces theirs.

A publish can be booked up to 365 days ahead. That is not a technical ceiling. A schedule set three years out fires against a template library nobody remembers configuring, carrying a body captured against a design system that has since moved on.

To book one:

1. Open the template in its editor from Templates.
2. Choose Schedule.
3. Enter the date and time under Publish at.
4. To begin a staged rollout at that time instead, switch on Start a staged rollout instead of publishing to everyone. In the designer the switch reads Start a staged rollout instead.
5. Choose Schedule.

A message gives the time it is booked for and says that what is in the editor now is what publishes. A banner stays on the template saying a publish is booked, and the Templates page shows a Scheduled badge.

What actually gets published

The body is captured when you book the schedule, not read from the draft when it fires.

This matters more than it sounds. If a schedule read the draft at midnight, every edit made in between would silently change what went live, and nobody would find out until the morning. A schedule is a decision that has been taken, so it holds its own copy.

The consequence is that editing the draft afterwards does not change what is booked. If you want the newer body to go live, book the schedule again.

A draft saved after the booking survives the publish. An ordinary publish clears the draft, because the person publishing is looking at it. Nobody is watching when a schedule fires, so it leaves any draft in place for somebody to decide about in the morning. The draft may be work that was meant for a later release.

The editor carries a banner for as long as a schedule is pending, so a hotfix published today cannot be quietly undone overnight by a schedule nobody remembered. The Templates view shows a Scheduled badge for the same reason, which is the version of the warning you see without opening anything.

When it fires

Schedules are checked every fifteen minutes. A publish lands within fifteen minutes after its instant, and never before it.

Sigil says “within fifteen minutes” rather than implying second precision, because that is what it can honestly promise. If you need something to be live by 09:00, book it for 08:30.

A schedule missed while Sigil was unavailable fires late rather than never. Late is recoverable and visible. Never is neither.

The same holds while your organisation is not being served, for example while a subscription has lapsed or the organisation is suspended. A booked publish stays pending and fires on the first check after signatures are being served again.

Scheduling a staged rollout

A schedule can start a staged rollout instead of publishing outright.

That is the difference between “switch everyone at midnight” and “begin the rebrand rollout at midnight”. The rollout then behaves exactly as one you started by hand: it steps up as the add-in reports the new version applying, and pulls itself back if it starts failing.

Publishing over a schedule

A schedule that fires while a rollout is running cancels that rollout.

This is the same rule a manual publish follows. The baseline the canary was measuring against is no longer live, so its numbers describe a choice nobody can make any more. The change log shows the scheduled publish itself; the rollout it cancelled does not get an entry of its own. A schedule booked as a staged rollout is different: it replaces any rollout already running on the template, starting the new one from the beginning.

Cancelling

Cancelling a booked publish leaves the live body exactly as it was, because nothing had changed yet. There is nothing to undo.

1. Open the template in its editor from Templates.
2. In the banner saying a publish is booked, or that a staged rollout starts, choose Cancel it.
3. Choose Cancel it in the confirmation.

A message confirms the scheduled publish is cancelled and the banner goes.

If it fails

A schedule that cannot publish is marked failed with the reason, and the row is kept rather than removed. It is not retried, because a publish that failed once will almost certainly fail again fifteen minutes later.

The portal does not show a failed schedule. The Scheduled badge and the editor’s banner simply disappear, the live body is unchanged, and no change log entry is written for the failure. So if a booked publish has not happened, open the template and check what is live: if the change is not there, book it again or publish it by hand. The stored reason can be read over the API, from GET /api/admin/templates/:id/schedule.

The commonest reason is that the template was deleted between booking the schedule and it firing.

A failed schedule is not retried. A publish that threw once will almost certainly throw again fifteen minutes later, and a schedule silently retrying forever is worse than one you can see has failed and why.

What is recorded

Booking, cancelling and firing each write a change log entry under the Scheduled publish action. A schedule that fails does not.

A schedule that fires is recorded against the person who booked it rather than against the system. A person decided this would happen, and the log should name them rather than make the publish look like it came from nowhere.

Who can do it

Anyone holding the templates capability. Of the built-in roles that is Admin and Editor, and an Admin can also give it to a custom role.

Where publish approval is switched on, scheduling needs an admin as well. Booking a publish is publishing, just later, so gating only the immediate route would leave “schedule it for one minute’s time” as the way around the control.