Nobody at the Desk: Getting Scheduled Publishing Through a UK Bank Holiday

There is a particular kind of confidence that comes from clicking Schedule at 4:55pm on the Friday before a bank holiday. The page is written, the approver has signed it off, the date is set for Monday at 9am. You close the laptop, and for roughly sixty-three hours everything is fine.

Then Monday arrives. The page doesn't. Or it does, but the old banner is still sitting at the top of the homepage, or the newsletter went out with the wrong link, or the embargo broke early because someone's CMS account was set to a different timezone. None of this is exotic. It's just the ordinary friction of publishing when nobody is at the desk.

Scheduled publishing is not a button. It's a chain of small dependencies, and a UK bank holiday is very good at finding the weak link in that chain.

What 'scheduled' actually means in your CMS

Before you trust the button, find out what it does. In most systems, scheduling sets a timestamp and a state change — the page moves from Draft to Published at a given moment. But the moment is interpreted by a server, in a timezone, behind a queue, in front of a cache. Any of those can shift things by minutes or hours.

Ask three questions of your own setup:

• Which clock is doing the publishing? Your CMS server, your database, or a job runner. If it's a container somewhere in Frankfurt running UTC, your 9am might behave differently than you expect.
• Is scheduling a queued job or a cron sweep? Some systems publish precisely; others check every five or fifteen minutes. That's fine for a blog post, less fine for a statement timed to a council meeting.
• Does scheduling survive a deploy? If your team pushes code over the weekend (they shouldn't, but they do), does the scheduled job get wiped? Some CMSs re-register queued jobs on boot; others quietly lose them.

None of these are reasons to avoid scheduling. They're reasons to test it once, on a quiet Tuesday, with a page nobody cares about.

The approval gap is the real holiday risk

Most scheduling failures I've seen aren't technical. They're human. The content lead scheduled the page, but the sign-off sits with a head of communications who is on a ferry to the Isle of Wight. Or the page is scheduled but still flagged as needing legal review, and the CMS publishes it anyway because the workflow wasn't actually enforced.

Before a bank holiday, do a simple audit of anything already in the queue:

1. List every scheduled item for the next ten days, including the days after the holiday.
2. Name the approver for each one, and check whether they'll be reachable.
3. Confirm the workflow state. If your CMS allows publishing without the final approval step, assume it will happen.
4. Check for orphaned drafts — pages scheduled by someone who has since left, or by an agency account you no longer control.

This is dull work. It takes twenty minutes. It is far less dull than explaining to a director why the press release about their new service went live on Easter Sunday with a placeholder image.

Timezones, BST, and the 1am surprise

UK web teams get two timezone headaches a year, and one of them usually lands near a bank holiday weekend. The clocks change in March and October, and any scheduled content that crosses those dates needs a second look.

If your CMS stores times in UTC and displays them in Europe/London, a page scheduled for 00:30 on the morning the clocks go back will appear at a reasonable hour. A page scheduled for 01:30 might land in a gap that doesn't exist, or run twice, depending on how the system handles the transition.

For most organisations this is an edge case. For anyone in local government, health, or transport — where a statement can be genuinely time-critical — it isn't. If you have content landing within a few hours of a clock change, either move it or test it.

Caches don't know it's a bank holiday

The page publishes. The CDN doesn't care. If your homepage is cached for an hour, or your listing pages are cached until a purge is triggered, a successfully published page can be invisible for longer than the person who scheduled it is awake to notice.

A few pre-holiday habits help:

• Know your purge path. Does publishing automatically purge the homepage, or does someone have to click something?
• Check the listing pages, not just the article. A press release can be live while the news index still shows last week's items.
• Look at sitemaps and feeds if they matter to you. They often update on a different schedule to the page itself.
• Test on staging first. If your staging environment has caching switched off, you aren't testing the thing that will trip you up in production.

The hand-off chain: newsletters, social, and the homepage slot

Scheduled publishing rarely happens in isolation. A page goes live, a newsletter links to it, a social post drops, the homepage banner rotates. Each of those is a separate system with its own schedule, and they rarely talk to each other.

Before a holiday, write down the chain for each big piece of content. Who or what triggers the newsletter? Is the social post scheduled in the same tool, or manually? Does the homepage banner need to be swapped by a human, and if so, will that human be near a laptop?

If the answer to any of those is "someone will remember," that's your risk. The fix is usually simple: schedule the newsletter earlier, point the social post at a stable URL, or accept that the homepage banner goes up on Tuesday. The wrong fix is to assume it'll all work out.

A checklist you can finish before you leave

Keep it short enough that people actually do it:

• Every scheduled item for the next ten days has a named, reachable approver.
• At least one person outside the content team knows how to unpublish a page.
• Timezone settings are confirmed for anything near a clock change.
• Cache purges are either automatic or assigned to a named person.
• The newsletter and social schedule has been checked against the CMS schedule.
• A test page has been scheduled and successfully published in the last month.
• There's a written fallback: who to call, how to reach them, and what to do if they don't answer.

That last point matters more than the rest. The goal isn't to eliminate risk — it's to make sure that when something goes wrong on a bank holiday Monday, the fix doesn't depend on one person's mobile signal at a National Trust car park.

Scheduling is a useful tool. It just isn't a substitute for knowing what happens after the button is pressed, and who's around if it doesn't.