Scheduled Publishing on a Static Site: What Each Mechanism Guarantees
Scheduled publishing on a static site is a job, not a field. Four mechanisms are in common use, each promises something different, and the right one depends on how wrong a late publish would be.
On This Page
The post was scheduled for nine on a Tuesday morning. At twenty to ten somebody asks in a channel why it is not live, an engineer opens a terminal, and the answer turns out to be that nothing was ever going to publish it. No error was raised. No alert fired. The mechanism did precisely what it promised, which was not what anyone in the room assumed it promised.
A database-backed CMS makes scheduling feel like a property of the content. You set a date, the record flips at that moment, and the next visitor sees the new state. A static site has nothing to flip at request time. The page either exists in the build output or it does not, which means scheduled publishing on a static site is not a field, it is a job, and somebody has to own it.
Four mechanisms are in general use: a scheduled build, a date-filtered build running on an interval, edge revalidation, and a person pressing publish. Each guarantees something different and fails in its own way. The choice is not about which is most elegant. It is about how wrong a late publish would be, which is a separate question from the one about editorial states covered in preview, draft and publish.
Why the date on the file does nothing by itself
A static build reads your content, decides which entries qualify, and writes HTML. Once that output is on a CDN it has no opinion about the clock. A file carrying a future date is inert until something reads it again. That is the whole mechanic, and almost every scheduling surprise traces back to somebody assuming otherwise.
So the sentence to hold on to is this: a static page goes live when a build says so, not when a date passes. The date is an instruction to a process that has to run. If no process runs, the instruction is a note in a file. This is the same reasoning that makes version control useful for marketing content: the repository records intent precisely, and the pipeline is what turns intent into a page.
Which is why the honest first question is not "does our stack support scheduling". It is "what runs, when, and who is told if it does not". Every mechanism below is an answer to that question, and the differences between them are entirely about failure.
Mechanism one: the scheduled build
When an editor sets a publish time, the system registers a job for that time. At nine the job fires, triggers a deployment, and the post appears. In practice this is a workflow dispatch on a timer, a hosting provider’s build hook, or a small scheduler holding a queue of pending publishes. On GitHub the plumbing is a scheduled workflow with a trigger step, and it is not much code.
What it guarantees
One deployment attempt at, or shortly after, the named minute. Nothing more. It does not guarantee the build succeeds, that the content was committed before the job ran, or that the job survived a change to the branch it was registered against.
How it fails
Silently, which is the worst property a publishing mechanism can have. If the job was never registered because the editor saved a draft and closed the tab before the workspace wrote it, nothing happens and nothing complains. If a queue is held in memory on a machine that restarts, the queue is gone. If the build fails at nine for an unrelated reason, the post misses its slot and the failure notification goes to engineering rather than to the person who scheduled it.
A scheduled publish that fails is an editorial incident wearing a build log. If the only alert lands in an engineering channel, the marketing team learns about it from a reader. Send the failure to whoever set the time, in words they can act on, with the retry button attached.
Mechanism two: the date-filtered build on an interval
Here nothing is scheduled per post. Every entry carries a publish date, every build filters out anything dated in the future, and a build runs on a fixed interval regardless of whether there is anything to publish. Hourly is common. Every fifteen minutes is not unusual on a small site.
What it guarantees
Two things, and they are stronger than they look. First, a post never appears early, because the filter runs on every build including the ones triggered by unrelated work. Second, a post goes live within one interval of its date, without anyone registering anything. There is no per-item state to lose, so there is nothing to lose.
How it fails
Granularity is the interval, and you cannot promise a nine o’clock publish on an hourly cadence. Most teams accept that; some cannot, because a press release timed to an announcement is either on time or embarrassing. The subtler failure is cost and noise. A build every fifteen minutes burns pipeline minutes all night for nothing, and a wall of green builds trains everybody to stop reading build notifications, so the one red build that mattered scrolls past unnoticed.
The mitigation is to make the interval build cheap and quiet: skip the deployment when the output is byte-identical, and only notify on failure. A structured workspace can also collapse the problem by writing the file at the moment it is due rather than in advance. A tool like Acrosite works this way: it generates the required files, commits them to GitHub and triggers the configured deployment, so the commit itself is the schedule and the site never carries content it is not meant to show yet.
Mechanism three: edge revalidation
The third mechanism skips the full build. The page is rendered once and cached, then invalidated on demand or on a timer, so a single route can be regenerated in seconds without touching the rest of the site. On modern frameworks this is a tag-based revalidation call or a timed cache lifetime. On a plain CDN it is a purge.
It is the only one of the four that scales to a large site with a busy publishing rhythm. When a full rebuild takes eight minutes, a fifteen-minute publishing interval stops being a schedule and starts being a queue. Revalidation breaks that link entirely: publish time becomes independent of site size.
It also introduces the most confusing class of bug on this list, because "published" now depends on layers you do not fully control. A CDN edge node may hold the old response. A stale-while-revalidate policy will deliberately serve the previous page to the visitor who triggered the refresh. Browsers cache. Preview links get shared and cached under the wrong key. And the index page listing your posts is a separate cache entry from the post itself, so the article can be live and unlinked, or linked and missing, for a window that nobody documented.
There is a second issue people meet late: a page that exists but is not yet due is often still reachable at its URL, because the route renders on request. If the date check lives only in the listing query, an embargoed post is a guessable link away from being public. Put the check in the page, not just the index, and return a 404 until the moment arrives.
Mechanism four: a person presses publish
Unfashionable, and correct more often than the other three combined. Somebody opens the workspace at nine, presses publish, and watches the deployment go green. No scheduler, no filter, no cache theory.
What it guarantees is something none of the other three do: a human confirmed the content was right, at the moment it went out, and saw it land. Nothing else on this list checks that the page actually renders. The cost is equally plain. It needs a person who is awake, available and not on leave, in a timezone that matches the slot. It does not survive a public holiday or a sick day. It quietly stops working the week your publishing volume triples.
We recommend manual publishing far more often than clients expect, particularly for teams publishing a few times a week where the real risk is a wrong page rather than a late one. It also pairs well with the argument for boring technology chosen deliberately: a mechanism with no moving parts has no moving parts to debug at eight on a Monday.
What each mechanism actually guarantees
Read this as four different promises rather than four qualities of the same promise. The right-hand column is the one that decides arguments.
| Mechanism | Guarantee | Granularity | Fails when |
|---|---|---|---|
| Scheduled build | One deploy attempt at the named time | To the minute | The job was never registered, or the build breaks |
| Date-filtered build on an interval | Live within one interval, never early | The interval | The pipeline is paused, or the interval is too coarse |
| Edge revalidation | Live seconds after the trigger | Near real time | A cache layer still holds the previous response |
| Manual publish | A person confirmed it went out correctly | Whenever the person is there | Nobody is available, or volume outgrows attention |
A schedule is a promise about a time. A mechanism is a promise about a condition. Most missed publishes are the gap between the two.
Choose by how wrong a late publish can be
Teams usually choose by what their stack makes easy. Choose instead by consequence, because that is the variable that changes between one content type and another on the same site.
- Sort content by embargo severity. A results announcement, an embargoed launch and a price change are timed commitments. A blog post, a case study and a hiring page are not. Most sites hold both kinds and treat them identically, which is the actual mistake.
- Set a tolerance in minutes, out loud. Ask the person who owns the content how late is unacceptable. "Within the hour" and "at 09:00 exactly" are different products, and the second one costs more to run.
- Pick the cheapest mechanism that meets the tolerance. If the answer is "within the hour", an interval build is the whole solution and you are finished. Do not build a scheduler because it feels more professional.
- Add a second mechanism only for the strict tier. A scheduled build for embargoed items, sitting on top of an interval build that catches everything else, is a sound pattern. The interval build becomes the safety net when the scheduled job misfires.
- Rehearse one failure before launch. Schedule something harmless, break the pipeline on purpose, and see who finds out and how. A mechanism nobody has watched fail is a mechanism nobody understands.
This ordering matters more than the technology choice, and it belongs with the people running content and organic growth rather than with the pipeline. Engineering can build any of the four in a day. Deciding which posts genuinely need a minute-accurate slot is editorial work, and it is the part that gets skipped.
The parts none of the four mechanisms fix
Publishing a page is one event. The things attached to that page are separate events, and they drift out of step with it constantly.
- The listing page. A post can be live at its URL while the index that links to it is still cached without it. Anyone arriving from the homepage sees nothing new.
- The sitemap. If the sitemap is generated at build time and the post arrived via revalidation, the URL is missing from the file search engines read first.
- Feeds and newsletters. An RSS feed regenerated on a different cadence will announce the post at a different moment, and email sends usually run on a third clock entirely.
- Social previews. Platforms cache Open Graph data aggressively. A link shared during the gap can keep showing the wrong title for a long time.
- Redirects and canonicals. If a scheduled post replaces an older one, the redirect has to ship in the same deployment, not the next one.
None of this is exotic, and all of it is invisible until a launch day. It is the same ordering problem described in crawl, render and index: the page existing and the page being discoverable are two different states, separated by time you did not plan for.
One paragraph, kept with the runbook. Name the mechanism, the tolerance, what else has to update, and who is told when it does not. Our parent company put the same argument plainly in what scheduling actually guarantees, and the companion piece on where drafts live and what stops them covers the state before this one.
Where we would start
For a marketing site publishing a few times a week, with no embargoed content: manual publishing, plus a date filter so nothing dated ahead can leak into a build somebody else triggers. That is two lines of logic and no infrastructure, and it fails in ways a person notices immediately.
For a site publishing daily, or one where content is written well ahead by people in other timezones: a date-filtered build on an hourly interval, with the deployment skipped when the output has not changed. Add a scheduled trigger only for the small set of items that genuinely need a named minute.
For a large site where a full rebuild is measured in minutes: edge revalidation, with the date check enforced on the page itself and a documented cache path. Budget real time for testing the caches; this is where an unglamorous maintenance arrangement earns its keep, because the failure modes only appear under traffic.
The concession worth making: if your team publishes constantly, from many people, with genuine embargoes and several locales, a static site is doing a great deal of work to imitate something a hosted editor gives away. That is a legitimate reason to change platform, and it is a different decision from the one this piece describes. If you are unsure which of the two you are facing, describe the publishing rhythm to us and we will say whether the mechanism or the platform is the problem, along with the build it would sit on.
Common questions.
Can a static site schedule posts without a server?
Yes. A static site schedules posts by running a build at the right moment rather than by checking a clock at request time. The usual options are a workflow triggered on a timer, a build that runs on a fixed interval and filters out future dates, or an on-demand revalidation call. All three work without a traditional application server behind the site.
Why did my scheduled post not publish?
The most common cause is that no process ran at the scheduled time. A file with a future date is inert until a build reads it again, so if the job was never registered, the queue was lost on a restart, or the build failed for an unrelated reason, nothing publishes and nothing raises an alarm. Check the build history for that window first.
How often should a scheduled build run?
Match the interval to the tolerance the content owner states. Hourly suits most marketing sites and costs very little. Fifteen minutes is reasonable for a busy newsroom, but it burns pipeline minutes overnight for nothing and floods notification channels, which trains people to ignore the one failure that mattered. Skip the deployment when the output has not changed.
Is incremental regeneration better than rebuilding the whole site?
It is better once a full rebuild takes long enough to block publishing, and worse before that point. Regeneration removes the link between site size and publish time, which matters at thousands of pages. It also adds cache behaviour you have to reason about, since a page can be regenerated while an edge node or a listing page still serves the previous version.
How do I stop a future-dated page being visible before its date?
Enforce the date check on the page route, not only in the listing query. If the route renders on request, the URL is reachable by anyone who guesses or shares it, even when no index links to it. Return a 404 until the publish moment arrives, and confirm that preview links use a separate path search engines cannot follow.
Which timezone should publish dates be stored in?
Store them in UTC and display them in the editor local time with the offset shown. Publishing mistakes cluster around daylight-saving changes and teams spread across regions, where a date written as a plain local string quietly shifts by an hour twice a year. Storing one absolute instant removes the ambiguity, and showing the offset stops editors guessing.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.