How scheduled publishing works for Git-backed websites

Scheduled publishing should put your content live at a chosen moment without leaking it early into your repository. That sounds obvious, but most Git-backed workflows quietly break the promise: the moment you "schedule" a post, the file is already committed to a branch, sitting in version control where anyone with repo access can read it, and where a misconfigured build can ship it ahead of time. This article explains why early commits happen, how Acrosite handles scheduled publishing by holding the approved draft in the app until the exact moment it is due, and what that means for timezones, logging, and your editorial calendar.

If you run a content team, an agency, or a single marketing site on a static framework, the gap between "this is ready" and "this is live" is where a surprising number of mistakes live. Getting scheduled publishing right removes a whole category of those mistakes.

The early-commit problem

In a plain Git workflow, there is no native concept of "publish this Markdown file at 9:00 AM Tuesday." Git tracks commits, not future intentions. So teams improvise, and every improvisation has a cost.

Draft branches and merge timing

A common pattern is to keep scheduled content on a draft or scheduled branch and merge it at the right time. The content technically isn't on the production branch yet, but it now lives in your repository history. Anyone with read access can see the unpublished post, embargoed announcement, or client material before it is meant to exist. For agencies juggling several client repositories, that exposure is a real confidentiality concern.

Cron jobs and scripts

Another pattern is a scheduled script — a cron job or CI task — that commits a file at a set time. This works until it doesn't. Cron runs on a server with its own clock and its own timezone. The script needs credentials to push to the repository. If the runner is down, the publish silently misses its window. If the script has a bug, it can commit the wrong file or commit twice. You have built a small, fragile publishing system that someone now has to maintain.

Manual reminders

The most honest pattern is also the least reliable: a calendar reminder that says "publish the launch post at 8 AM." It depends on a person being awake, online, and free at that exact minute. It does not scale past a handful of posts, and it fails on holidays and across timezones.

How Acrosite holds the draft until it is due

Acrosite is a Git-backed platform: your content lives as Markdown or MDX with YAML frontmatter in your own GitHub repository, and non-technical people publish through the dashboard instead of editing files directly. Scheduled publishing fits into that model without breaking the core guarantee that nothing reaches your branch before its time.

When you schedule a Content Item, the approved draft stays inside Acrosite. It is not committed to a branch, not staged, and not visible in your repository. There is no early commit and no hidden file in Git history. At the scheduled moment, Acrosite performs the same publish it would have done if you had clicked publish manually: it validates the content, commits the Markdown or MDX file with its frontmatter to the connected repository on the configured branch and content path, and saves the commit SHA.

This matters because the commit is the publish. In a Git-backed site, the file landing in the repo is the event that makes content real and that downstream tooling reacts to. By deferring that single action to the scheduled time, Acrosite keeps "ready" and "live" cleanly separated.

The workflow looks like this:

1. An editor or Team Member writes a Post, Page, or entry of a Custom Content Type in the dashboard.
2. The draft stays private in the app and can move through review.
3. Someone schedules it for a specific date and time instead of publishing immediately.
4. Acrosite holds the approved draft — no branch commit yet.
5. At the scheduled time, Acrosite validates and commits the file to the configured branch and content path.
6. The configured deployment trigger profile tells your hosting provider to rebuild.

A typical committed file is plain and reviewable, for example a post written to content/posts/:

---
title: "Spring product update"
slug: "spring-product-update"
date: "2026-04-14T09:00:00-04:00"
status: "published"
description: "What changed this season and why it matters."
---

Body content in Markdown or MDX goes here.

Because the same frontmatter and path conventions apply whether you publish now or later, scheduled output is identical to manual output. Your Next.js or other Git-backed static framework sees no difference.

After the commit: triggering deployment

Committing the file is necessary but not sufficient — most static sites need a rebuild to render the new content. After the scheduled commit lands, Acrosite uses your configured deployment trigger profile to tell the hosting provider to rebuild, which can be automatic or manual depending on how you set it up. This is deployment visibility: you can see that the rebuild was requested rather than guessing whether your provider noticed the commit.

That separation is deliberate. The commit and the deployment are two distinct steps with two distinct records, so if a build fails you can tell whether the problem was the content reaching Git or the provider rebuilding from it. You can read more about how the publish side works on the GitHub publishing page and how scheduling specifically behaves on the scheduled publishing feature page.

Timezones, accuracy, and what gets logged

Timezone ambiguity is where naive schedulers fail most often. A time without a zone is a guess, and a guess that publishes a press release an hour early is a bad day. When you schedule a Content Item, treat the time as anchored to a clear timezone rather than an implicit server clock, and confirm the intended moment before saving. Storing an explicit offset in the date frontmatter, as in the example above, keeps the intended instant unambiguous for both Acrosite and your framework.

Everything that happens at publish time is recorded. Publish Logs capture each publish attempt's steps — content validated, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens, deploy hook URLs, or raw provider payloads. Deployment Logs record the result of the deployment trigger itself. If a scheduled publish fails, you are not left guessing: the attempt is logged, and where it is safe to do so, the publish can be retried. This visibility is the practical difference between a managed scheduler and a cron job that fails into silence.

Tying scheduling into the editorial calendar

Scheduling a single post is useful. Scheduling a quarter of content is where it changes how a team works. The Content Calendar gives editors a view of what is queued and when it will go live, so a marketing lead can plan a cadence instead of reacting day to day. Pairing the calendar with review keeps quality intact: a draft can move through the Review Queue, where internal reviewers sign off, and Client Reviewers — invited per Project and able to see only the content assigned to them — can comment and Approve or Request Changes before anything is scheduled.

That ordering matters. Approval happens while the draft is still held privately in the app; scheduling commits the already-approved content at the chosen time. Nothing reaches the repository for a Client Reviewer to stumble onto, because Client Reviewers have no GitHub access in the first place. For teams running several client sites, that combination — private drafts, scoped review, and deferred commits — is the whole point.

A realistic agency rhythm might be:

• Draft a batch of Posts for a Client across the month.
• Route each through the Review Queue and Client Reviewers for sign-off.
• Schedule the approved items across the Content Calendar.
• Let Acrosite commit each at its time and trigger the rebuild.
• Check Publish Logs and Deployment Logs the next morning to confirm clean runs.

You can see how the review and planning pieces fit together on the client review and content calendar pages, and the broader model on the how it works overview.

When scheduling is the right call

Scheduled publishing is not always the answer — sometimes you just want content live now, and manual publishing is the simpler path. Reach for scheduling when timing genuinely matters: coordinated launches, embargoed announcements, time-zone-sensitive releases, or a steady content cadence you want to set up once and stop thinking about. The benefit is not just convenience; it is the guarantee that approved content waits in the app, out of your repository, until the precise moment it should appear.

Used this way, scheduling becomes a quiet reliability feature rather than a flashy one. Your repository stays clean, your team stops babysitting cron jobs, and your published history reflects exactly what went live and when.