Scheduled Publishing

Every entry can carry two optional dates: publish_at (when it goes live) and expire_at (when it stops being served). Studio uses them as a delivery window and rebuilds your delivery when a boundary passes, so nobody has to press a button at midnight.

How It Works

• publish_at and expire_at are stored in the entry's meta in Git, never in its content data
• They never change the entry's status. A past publish_at does not publish a draft; publishing is still a status change
• They gate delivery of entries that are already published: such an entry is served from publish_at (inclusive) until expire_at (exclusive)
• A future publish_at on an entry that is already published takes it out of delivery until that date
• Set expire_at after publish_at: an expire_at at or before publish_at leaves an empty window, so the entry is never served
• A date that cannot be read excludes the entry from delivery, and project health reports it as a warning

Setting the Dates

The content editor in Studio does not have date fields for scheduling. You set the dates in one of two ways:

• Through the AI chat. Ask the agent to schedule an entry; it saves publish_at and expire_at (ISO 8601 date-times) next to the content in the same save. null clears a date, and leaving a date out keeps it unchanged
• Through the REST API. POST /api/workspaces/{workspaceId}/projects/{projectId}/content/{modelId} accepts publish_at and expire_at beside data. You need permission to write content. See the Content API

TIP

Scheduling a draft does not publish it. Set the status to published as well; the dates then decide when the published entry is actually served.

What You See in Studio

In the entry list, a published entry outside its window shows a badge instead of its status:

Badge	Meaning
scheduled	Published, but publish_at is still in the future. Hover for the go-live date
expired	Published, but expire_at has passed and it is no longer served. Hover for the date

The CDN view also lists the pending scheduled boundaries under Scheduled boundaries in the deploy hook section. Owners and admins see it.

What Happens When a Date Passes

Every save that carries a future boundary registers it with Studio's scheduler. Once a minute the scheduler claims the boundaries that are due and, per project:

1. Rebuilds the CDN bundle, if CDN delivery is on, so the bundle reflects the new window
2. Fires your deploy hook, if one is set and Deploy at scheduled publish / expiry is on
3. Emits the schedule.fired webhook event with the boundaries that fired (model, entry, locale, kind, and fire time)

A boundary missed during downtime is picked up on the next tick. Hook delivery is at-least-once, so your host may occasionally receive a repeat trigger.

Static sites need a deploy hook

If your site is built statically from the content files, nothing rebuilds it when a date passes unless you connect a deploy hook. See Deploy Hooks.

Availability

Scheduling is part of the content engine and is not tied to a plan feature key. The deploy hook and the CDN bundle it triggers are described on their own pages.