Schedule publishing for posts and pages
How to set a future publish time, manage time zones, build a recurring publish window, and hold content under embargo until a chosen release.
Scheduled publishing is how you decouple writing from the moment of release.
A draft moves to a queue with a chosen go-live time, and the platform handles the release while the team is doing something else.
This page walks the full scheduling workflow for an SGEN site — picking a publish time, working across time zones, scheduling a series of posts on a cadence, holding sensitive content under embargo until a release moment, and clearing the schedule queue when plans change.
The page is written for two operating modes.
The first is editorial cadence — a content team that maintains a regular publishing rhythm and wants every piece to land at a predictable moment.
The second is launch coordination — a product, partner, or marketing moment where every part of the story has to appear at exactly the same time across many surfaces.
Both modes share the same scheduling surface, and the discipline is the same — choose the moment, confirm the time zone, hold the draft until the queue fires.
What is this for?
Use this page when you need a post or page to go public at a moment in the future without anyone clicking Publish at that moment.
The scheduling layer covers blog posts, pages, what's-new entries, and changelog entries.
It also covers the embargo pattern — a draft that is locked from public access until a release moment.
The page is a how-to.
It does not cover the underlying publish flow at the platform level, the page-render cache, or the search indexing pipeline.
Those topics live in the Publishing Lifecycle Reference.
The scheduling layer is the customer-facing surface; the lifecycle layer describes what happens in the moments around a publish event.
Good use cases
- A weekly blog cadence where posts are written ahead of time and queued to release on a fixed day and hour.
- A product launch where the announcement post, the landing page, the changelog entry, and the what's-new card all need to flip live at the same moment.
- A partner embargo where a piece of content is shared with reviewers before public release and must stay non-public until the embargo lifts.
- A seasonal content series — twelve posts written in a single block and scheduled across the run of the season.
- A coordinated release across time zones where the chosen go-live moment is the same wall-clock time in every regional audience.
What NOT to use this for
- Routing visitors to a temporary holding page before launch. Use a redirect rule instead — a scheduled draft is invisible until the moment it fires, so a redirect from the eventual public URL is the right tool for a pre-launch page.
- Reverting a published piece of content. Scheduling is forward-looking; to take a published item off public, change the status to draft or archived. The Publishing Lifecycle covers this path.
- Pre-staging a single field change inside an already-published page. Scheduling targets the post or page as a whole. For staged field changes, use the page-staging surface.
- Holding content for an indefinite period. A scheduled item needs a publish moment. For long-term holds with no chosen release moment, keep the item in Draft status.
How this connects to other features
- Publishing Lifecycle — defines the states a post or page can hold and the transitions between them; scheduling is one transition path.
- Audit Log — every schedule action and every queue fire is recorded; use the log to confirm a scheduled item published on time.
- Optimize for SEO — search indexing follows publish events, and timing a publish near the start of a regional working day lifts the chance of fast indexing.
- Back up and restore your site — take a manual snapshot before a coordinated multi-asset launch so a misfire has a recovery path.
Before you start
- You are signed in as a user with publish permission for the post or page. Editors with draft-only permission can save a draft but cannot set a schedule.
- The post or page is in a complete enough state to release. A scheduled item that fires while in a half-built state lands on the public surface; the queue does not check for completeness.
- The site's time zone is set correctly. Schedule times use the site's configured time zone unless an explicit zone is picked at scheduling time.
- A small visual review has run on the draft. The most common scheduling regret is publishing a piece with a typo in the title or a broken visual — neither of which the queue catches.
- For an embargoed release, the embargo end moment is agreed with anyone who has been given pre-release access.
Where to find it
The per-post surface is the Schedule control on the post or page edit screen — to the right of the Publish button.
Clicking the Schedule control opens the schedule panel for that single item.
The portfolio surface is the admin → Content → Scheduled which lists every post or page in the site that has a future publish time set.
Use this surface to scan the queue, edit a schedule, or clear a queued item.
For an agency or in-house team running many sites, SG-Dashboard → Schedule rolls up the queued items across every site in the account.
This surface answers the question "what is releasing today across the portfolio" in one view.
Steps
The workflow has six parts — set a one-off schedule, confirm a time zone, build a recurring schedule, set an embargo, run a coordinated multi-asset release, and clear a queued item.
The steps below cover the per-post surface.
1. Set a one-off publish time
Open the post or page in the admin.
Click the small arrow next to the Publish button.
The publish dropdown opens with three options — Publish now, Save draft, and Schedule.
Click Schedule.
The schedule panel opens with a date field, a time field, and a time-zone label.
Pick the date in the date field — the calendar opens to today's date by default.
Pick the time in the time field — the time defaults to the next round hour.
Confirm the time zone shown below the time field.
By default the panel uses the site's configured time zone.
If the post should publish at a different region's wall-clock time, click the time-zone label and pick the right zone from the list.
Click Schedule Publish.
The post status changes to Scheduled and the schedule moment appears in the panel header.
The post is now invisible to the public until the schedule fires.
The Audit Log records the schedule action with the actor and the chosen moment.
2. Confirm the time zone behavior
The site's time zone is set in the admin → Settings → Site → Localisation.
The chosen zone is the default for every scheduled publish.
A site with a global audience usually picks the home-region zone; a multi-region team often picks UTC for predictability across the team.
Two ways the time zone shows up in the schedule surface.
The first is the default — every new schedule reads the site's zone.
The second is the override — at scheduling time, the panel allows a different zone for that single publish.
Use the override when the publish moment is anchored to an audience region different from the site's default.
A campaign aimed at a European audience may want a 9:00 AM CET release even if the site's default is set to UTC.
The schedule panel shows the picked moment in three forms — the chosen wall-clock time, the equivalent UTC moment, and the time-until-release in human-readable form.
The three forms are a cross-check; if the time-until-release reads "in 18 minutes" but the chosen wall-clock looks like next week, the zone is wrong and the schedule needs adjustment.
For teams that operate across many time zones, the convention of scheduling in UTC and converting in the picker is usually quieter than scheduling in local time and trying to remember whether daylight-saving has flipped recently.
3. Build a recurring publish window for a series
For a content series with a regular cadence — a weekly post, a daily card, a monthly roundup — open the post template that the series uses and click Create Series Schedule in the schedule panel header.
The series schedule panel opens with cadence options — daily, weekly, fortnightly, monthly — and a start moment.
Pick the cadence and the start moment.
Pick the Series count — the number of posts in the series, or Open-ended for a series with no defined finish.
The series schedule binds the chosen cadence to the post type.
New posts saved under the bound type carry an auto-suggested schedule moment in the publish panel.
The auto-suggestion is the next open slot in the cadence; the operator can accept the suggestion or override it.
A series schedule is a planning aid, not a publishing rule.
The platform does not auto-publish a draft that has not been written; the cadence offers the next time slot, and the post still needs an explicit Schedule action to enter the queue.
Open the admin → Content → Scheduled and switch to the Series view to see every series schedule in the site, the next three open slots in each, and which slots have an active scheduled post.
4. Set up an embargo for sensitive content
An embargo is a publish that is held until a chosen moment and is non-public until that moment.
The scheduling layer handles this pattern directly.
Open the post or page in the admin.
Click the schedule arrow next to Publish.
Pick Schedule and set the embargo lift moment as the schedule time.
Open the Pre-release access tab in the schedule panel.
The tab lists users who have been granted access to the draft before the embargo lifts.
Add reviewers by their account email.
A reviewer with pre-release access can view the draft on a private preview URL but cannot share the URL — the preview URL carries a session-scoped token that does not work for an unauthenticated visitor.
Pick the Embargo policy — Standard, which allows reviewers to read and comment, or Read-only, which removes the comment surface for reviewers.
Save the schedule.
The post is now in embargo. The Audit Log records the embargo action, the reviewer list, and the chosen lift moment.
When the lift moment arrives, the scheduled publish fires as a normal publish.
The post moves to Published status; the pre-release access becomes irrelevant because the post is now public.
Reviewers stay listed in the Audit Log entry for post-launch traceability.
For a launch with multiple embargoed items, set the same lift moment across each item and the items will fire together.
The Multi-asset Release step below covers this pattern in more detail.
5. Run a coordinated multi-asset release
A launch usually carries more than one item — a blog post, a landing page, a what's-new card, a changelog entry, sometimes a docs page update.
Coordinating these so they appear at the same moment is the most common multi-asset scheduling pattern.
Open the admin → Content → Scheduled and click New Release Group in the top right.
The release group panel opens with a name field and an empty asset list.
Name the release — Spring product launch 2026, Partner X announcement, Quarterly summit recap.
Click Add Asset and pick each draft that should ship with the release.
The picker shows every draft in the site and indicates the asset type next to each.
Set the Group publish moment.
Every asset in the group adopts this moment when the group is committed.
Individual assets cannot override the group moment; the point of the group is the synchronized publish.
Click Commit Release Group.
Every asset moves to Scheduled with the group moment, and the Audit Log records the group commit.
When the group moment arrives, every asset publishes in the same window.
The platform fires the assets in fast succession; the gap between the first and the last asset is small enough that no audience sees a half-built launch.
Before the group fires, run a final review.
Open each asset in the group, read the final state, confirm visuals are in place, run any internal links in the asset to confirm they point at the right destinations.
The Audit Log captures the review steps if reviewers comment on the drafts during the review cycle.
For a launch with external press coverage, time the group moment to align with the press window.
The group fires within seconds; that level of synchronization is what allows the team to point reviewers at the public URLs from the moment the embargo lifts.
6. Clear or reschedule a queued item
Plans change.
A scheduled post needs to move, or to come out of the queue entirely.
Open the admin → Content → Scheduled.
Find the post in the list and click the row.
The row expands to show the current schedule moment, the actor who set it, and the actions available.
Click Reschedule to pick a new moment.
The schedule panel opens with the existing values pre-filled; change the date or time and save.
The Audit Log records the reschedule with the previous moment and the new moment.
Click Cancel Schedule to take the post out of the queue without publishing.
The post returns to Draft status; the draft content is unchanged.
The Audit Log records the cancellation.
Click Publish Now if the team has decided the release should ship immediately rather than wait.
The publish fires within seconds; the Scheduled state ends and the post moves to Published.
For a release group, opening the group from the schedule list shows the same set of actions but applied to every asset in the group at once.
Cancelling the group cancels every asset; rescheduling the group reschedules every asset.
A reschedule on a release group invites a quick check that every asset is still ready for the new moment.
A change of plan often touches asset content as well as timing; the review cycle stays the same regardless of the trigger.
What success looks like
A scheduled item is set correctly when the post status reads Scheduled in the publish panel, the schedule moment shows in the post header in both wall-clock and time-until-release form, and the entry appears in the admin → Content → Scheduled with the chosen moment.
A scheduled item publishes successfully when the post status flips to Published at the scheduled moment, the Audit Log records the publish event, the public URL serves a 200 response with the post content, and any release-group siblings publish within the same short window.
An embargo lifts cleanly when reviewers lose their pre-release access at the lift moment, the post becomes publicly readable, and the post URL appears in the standard publish surfaces — homepage feed, category indexes, RSS, sitemap.
What to do if it does not work
| Symptom | Likely cause | Fix |
|---|---|---|
| Schedule moment shows in the panel but the post stays in Draft | Operator clicked Save Draft instead of Schedule Publish | Open the post; click the schedule arrow; pick Schedule; click Schedule Publish to commit |
| Post fired at the wrong wall-clock time | Time-zone override did not apply | Reschedule with the right zone picked explicitly; confirm the moment in the three time forms in the panel |
| Release group fired but one asset stayed in draft | The asset was edited after the group commit and the edit reset the schedule | Open the asset; reschedule to the next available moment; consider re-running the group with all assets reviewed at once |
| Embargo lifted but a reviewer still appears in the reviewer list | Audit Log retains the historical reviewer record after publish | The retained record is expected; it is post-launch evidence of who had pre-release access |
| Cannot pick a past moment for the schedule | The platform requires a schedule moment in the future | Pick a future moment; if the intent was to publish immediately, click Publish Now instead |
| Series cadence not suggesting a next slot for a new draft | The series schedule has not been opened in the current edit session | Open the post; the schedule panel reads the series binding when the panel opens |
| Time-until-release reads negative on a freshly-scheduled post | Operator picked a moment before the current site clock | Reschedule with a moment in the future |
| Audit Log does not show the schedule event | Action did not reach the server | Refresh the post page; confirm the status reads Scheduled; re-run the schedule action if needed |
Examples
Example A — weekly Tuesday-morning blog cadence.
A content team writes posts ahead of time and wants each post to publish at 8:00 AM site time every Tuesday.
Operator opens the blog post template, creates a series schedule with cadence Weekly, start moment Tuesday 8:00 AM, series count Open-ended.
Each new draft now suggests the next open Tuesday slot in the schedule panel; the operator accepts the suggestion and clicks Schedule Publish.
Over six weeks, six posts ship at 8:00 AM Tuesday with no manual launch work.
Example B — coordinated product launch.
A product team is launching a new feature on a Thursday at 2:00 PM UTC.
The launch has a blog post, a landing page, a what's-new card, and a changelog entry.
Operator opens the admin → Content → Scheduled and creates a Release Group named Spring product launch 2026.
Adds all four assets, sets the group moment to Thursday 2:00 PM UTC, commits the group.
At 2:00 PM UTC on the day, the four assets publish in the same five-second window.
The press kit pre-distributed to reviewers links to the public URLs which become live at exactly the right moment.
Example C — partner embargo with reviewer access.
A partner agreement requires an announcement to be shared with the partner's PR team three business days before public release.
Operator drafts the post, opens the schedule panel, picks the public release moment, opens the Pre-release access tab, adds three partner email addresses, sets the embargo policy to Standard so the partner can comment.
The partner reads the draft on the private preview URL, requests two small edits, the operator applies them.
At the scheduled moment the post publishes and the partner-side announcement goes out in parallel.
Example D — quarterly content series scheduled in one block.
A research team has prepared twelve weekly research notes for a quarterly series.
Operator opens each draft, picks Schedule, sets the moment to the corresponding Tuesday at 9:00 AM, saves.
All twelve drafts move to Scheduled status.
the admin → Content → Scheduled shows the queue in chronological order; the team can spot-check the schedule once a week and rest assured the queue is firing on cadence.
Example E — last-minute reschedule of a launch.
A planned Friday launch needs to move to the following Monday because a partner-side dependency slipped.
Operator opens the admin → Content → Scheduled, finds the Release Group, clicks the row, clicks Reschedule, picks the new Monday moment.
Every asset in the group adopts the new moment.
The team uses the extra weekend to add an additional sentence to the blog post and the change is captured in the next group review.
Common questions about scheduling
Does scheduling work on all content types?
Scheduling covers blog posts, pages, what's-new entries, and changelog entries.
Other content types — comments, forum posts, customer-account profile fields — do not carry a schedule control because they are not publishing surfaces in the same sense.
What happens if the site is down at the scheduled moment?
The platform retries the publish on a short cycle.
A short outage at the moment of the scheduled fire shifts the publish by seconds, not hours.
The Audit Log records both the scheduled moment and the actual publish moment; if the actual differs from the scheduled by more than a minute, the entry carries a note explaining the gap.
Can I schedule a publish that has already been published once?
Yes — for a re-publish event.
Take the post off public by switching it to draft, edit the draft, then schedule a new publish moment.
The Audit Log records the full history of publish events for the post.
Does the platform send a notification when a scheduled publish fires?
Yes.
Authors and editors with notification permission receive an in-app and email notification when a scheduled post or page publishes.
The notification carries the post title, the public URL, and the publish moment.
Can multiple operators schedule the same post?
The most recent schedule action wins.
If two operators edit the schedule of the same post in quick succession, the later action overrides the earlier one.
The Audit Log records both actions for traceability.
How far ahead can I schedule a publish?
Up to one calendar year in the future.
Schedules that need to extend beyond a year are usually a series schedule case; the series binding handles the cadence and individual posts are scheduled within the year-ahead window as drafts become ready.
Plan for large-site and multi-site scheduling scenarios
A high-cadence single site or a multi-site portfolio raises the operational stakes of scheduling.
The mechanics stay the same; the discipline changes.
Large single-site planning
A site that ships many posts per week needs an editorial calendar that the team treats as the single source of truth.
The Scheduled view is the platform-side reflection of that calendar; the editorial calendar — usually maintained outside the platform in a shared workspace — is the planning surface.
A weekly review walk through the Scheduled view answers two questions — is every slot in the cadence filled, and is every scheduled item ready to ship at its slot.
The walk takes a few minutes and prevents a missed slot or a half-ready ship.
For a site with a heavy launch cadence, take a manual backup before a multi-asset release group fires.
The backup is a recovery path if a misfire produces an unexpected public state.
Pair every series schedule with a small editorial brief that names the cadence, the audience, the success measure, and the retirement criteria.
A series that has gone past its useful life is easier to retire when the retirement criteria were written up front.
Multi-site portfolio planning
For an agency or in-house team running many sites, the portfolio surface in SG-Dashboard is the right lens.
Open SG-Dashboard → Schedule for a single roll-up of every scheduled item across every site in the account.
The view answers questions about portfolio-wide launch density — is today a quiet day or a heavy launch day, and is the workload spread across enough operators to give each launch a clear owner.
Pick a portfolio cadence and write it down.
A typical agency cadence — weekly review of the portfolio Scheduled view, monthly review of series schedules per site, quarterly audit of release groups that have shipped and the lessons that came out of them.
For an enterprise account with regulatory weight on its publish events, the Audit Log entries for scheduled publishes become a compliance artifact.
The log carries the actor, the moment scheduled, the moment fired, the reviewer list for embargoed items, and any reschedule history.
Export the log on a regular cadence and store the export with the team's compliance records.
A documented portfolio playbook lifts every team member's scheduling work.
The playbook is a small investment; the cost of an uncoordinated launch — when the docs land twelve hours after the marketing post — is the cost the playbook prevents.
Schedule audits and lessons learned
After every launch group fires, run a short retrospective.
Open the Audit Log filtered to schedule events for the relevant window.
Read the entries — when each asset moved to Scheduled, who set the moment, when the group fired, how long the spread between first and last asset took.
Compare the launch outcome against the plan.
A clean launch fires as expected; a noisy launch shows up as gaps in the entries, last-minute reschedules, or assets that needed to ship outside the group.
Capture the lesson in the team's internal runbook.
A lesson is a sentence — "next time, add the changelog entry to the group as soon as the post is drafted" — rather than a paragraph.
Lessons accumulate over many launches and become the team's institutional memory.
For a multi-site portfolio, hold a quarterly cross-site retrospective.
Pull the schedule events across every site for the quarter, identify the patterns that recur across sites, and adjust the playbook.
Patterns that show up in three sites in one quarter are usually structural; patterns that show up in one site are usually site-specific.
The retrospective discipline is the difference between a team that learns from every launch and a team that repeats the same surprises across many launches.
