How scheduled publishing works

A scheduled publish is not a state an item is in. It is a time written on the item, plus a job in the database that looks for times which have passed. By the end of this page you'll know what that job does when the time comes, why an item can sit on processing…, what operators receive and when, and why you can move a schedule without losing approvals.

A schedule is a time on the item

People who hold Publish set it from the editor's Publish card, Scheduled (opens the admin console), the calendar or the bulk actions on All content. Setting a time is publishing in advance, so the database refuses to set or move one for anyone without Publish, and records who set it; cancelling a schedule needs only Edit content, because it never publishes anything. The item keeps its status — Draft or In review — and nothing reaches operators until the time comes. Publishing the item by hand clears the schedule, and so does sending it back with Request changes, so a bounced item can't go live on its old time.

Your clock, one moment

Every scheduling screen reads and shows times in your time zone — the one in your profile under Account settings, or your browser's if you haven't set one — and names that zone beside the field. What is stored is a single moment, so a colleague elsewhere sees the same publish on their own clock: 06:00 in Brisbane reads as 04:00 in Perth.

The conversion uses the zone's offset on the scheduled date, not today's, so a publish set across a daylight-saving change still lands on the hour you typed. Dragging an item to another day on the calendar keeps its time of day in your zone.

What the job does when the time comes

A job in the database runs every minute. Each run takes every item whose time has passed and that is not yet published, and publishes it as it stands at that moment — draft or in review; the review does not have to be finished — but only while the person who scheduled it still holds Publish in your agency. Someone who loses the permission before the time cannot have their schedule go live. The editor's publish checks are not run again: they ran, if at all, when the schedule was set (see How publish checks work).

In the same step the job stamps a publish date if the item has none, clears the schedule and queues a push notification. Operators' apps download the item at their next sync. A schedule therefore lands within about a minute of its time, and a time already in the past publishes at the next run.

Sign-off holds an item; it doesn't fail it

Before publishing, the job checks two-person sign-off: the item's own Required box and any approval policy that matches it, counting approvals on the current version from people other than the author and the person who scheduled it — on this path the scheduler is the publisher, so approving an item and then scheduling it yourself does not make two people. An item without enough approvals, or whose scheduler no longer holds Publish, is skipped. It stays queued and is looked at again every minute; once the problem is fixed, it publishes at the next run. On Scheduled it shows processing… for the first three minutes past its time, then waiting with the reason.

Skipping rather than failing means one held item never stops the rest of that minute's batch, and never quietly loses its schedule. The cost is that a held item waits without telling anyone — the job sends no notification when it skips something.

Moving a schedule keeps the version

Approvals, and operators' acknowledgements, are pinned to the item's version. Setting, moving or cancelling a publish time does not change the version, because a publish time says nothing about the words anyone approved. Reschedule an approved item as often as you need; its approvals stand.

A change to the item itself — its title, summary, body, cover or guide appearance — does move the version. On an item that needs sign-off, approvals on the old version stop counting, and the job holds it until it is re-approved. See Versions and history.

An editor left open while someone reschedules from Scheduled or the calendar won't put the old time back, either: the editor sends a publish time only when you change the field yourself.

The push afterwards

The push is queued in the same step as the publish, and a separate job works through the queue every minute. Every active member of your agency who hasn't switched notifications off gets a push titled with your agency's name, with "New:" or "Updated:" and the item's title underneath, limited to the guides each person chose to hear about. It appears in the item's delivery record on its Notify operators card.

If delivery fails, it is retried after 1, 2, 4, 8 and then 16 minutes — six attempts, about half an hour in all. After that the push is marked undelivered for ROK's platform team, who can send it again. Delivery is at-least-once, so an operator may occasionally get the same push twice. If the item is unpublished before the push goes out, nothing is sent.

Publishing by hand sends no push by itself; use Notify operators on the item when people need to know now. More in How push notifications work.

What this means in practice

• waiting means the job is skipping it. "Waiting for approvals, or the person who scheduled it can no longer publish." — open the item: its Two-person sign-off card shows how many approvals the current version still needs; if that is not it, reschedule it yourself. "Not scheduled by a publisher — reschedule it to queue it." — the schedule has no recorded scheduler; set it again.
• Edits made after scheduling go out with it. The job publishes whatever the item says at that moment — and on a gated item, those edits also reset the approvals.
• The publish is instant on the server, not on devices. Operators see the item at their next sync; the push is what prompts them to open the app.
• A schedule is not a fourth status. The item is a draft or in review right up to the minute it publishes — see How publishing works.