ZyanDocs

Publishing and the site deploy gate

The three publish modes, what published actually means, how the public URL is confirmed, and what to do when a commit lands but the page is not live.

A finished post reaches the website by being committed to its repository. How it gets there is the schedule's publish mode. Whether it is then genuinely readable by a visitor is a separate question, and Zyan treats it as one.

That distinction — committed, deployed, verified live — is the whole of this page.

Before you start

You need a per-tenant GitHub App installation with access to the website's repository, installed by the account owner on SettingsIntegrationsGitHub. For the deploy check, that installation also needs the Actions: Read permission.

The three publish modes

Set on the schedule card, or in the Autopilot modal, under This schedule publishes via.

ModeWhat happensUse it when
Review PRThe post is committed on a branch and a pull request is opened for youYou review every post before it goes out
Auto-mergeA pull request is opened and merged automaticallyYou want the audit trail of a PR without the wait
Direct pushThe post is committed straight to the publish branchThe site is trusted to publish unattended

Direct push needs trusted auto-publish

Direct push is refused unless the schedule's Approval mode is Trusted auto-publish. If posts keep stopping at a pull request when you expected them live, check the approval mode before anything else.

What happens when GitHub is not connected

The platform answers with a plain configuration response rather than failing silently. More usefully, the draft is preserved: the post moves to needs-review carrying its change set, so Approve & publish re-commits it once GitHub is connected — with no extra writing cost.

Publishing is also gated by a platform-level arm

Writing to tenant repositories depends on a platform switch. With it off, every repository write returns a configuration response. If publishing is refused for every website in the workspace, it is not the schedule — ask your platform operator.

What published actually means

Three different things, in order.

Committed

The post is on the publish branch. This is what the publish step does

Deployed

Your own site repository built and shipped that commit. Zyan does not run that build

Verified live

Zyan re-fetched the public URL until it resolved

Only the third one is a link you can send a client. Until the check passes, the URL on the post is a guess.

The public URL is chosen from the writer's own reported path, the repository's route map, a path mapping, or a derived /blog/{slug} — then confirmed by that live check. Once verified, it is the link that appears on the post, on the client's Content Center task, and in reports. That is the URL to send a client.

The site deploy gate

After a direct-push commit on a Git-deployed site, the platform reads the site repository's own GitHub Actions runs for that commit. If the deploy failed, the post is marked Site deploy failed — not live rather than being claimed as published.

Open the post drawer

From ContentDrafts, or the week strip on the Content tab.

Follow Open the failed run

It links to the GitHub Actions run that failed.

Fix the site repository and push

The failure is in your site's build, not in Zyan.

Let the re-check catch up

The post is re-checked automatically and goes live with the next successful deploy that contains your commit.

Re-checks widen over time

The first re-checks come within 30 minutes, then up to every 6 hours, then monthly after 14 days. A post fixed two weeks later will clear, but not instantly. Re-checks only apply to the direct-push lane — a pull-request post is not deploy-checked, because the deploy runs on the merge commit.

If the GitHub App lacks Actions: Read on the repository, the deploy status reads unavailable and no failed run is linked. The drawer names the fix. Grant that permission to the installation and wait for the next re-check.

Publishing notes

A post's drawer carries Publishing notes — things the platform noticed while publishing, such as a duplicate topic, an unverified blog listing, or an oversized file that was left out.

Notes never hold a post

Advisories are informational. Only two classes of problem actually stop a post: security problems (a protected page, a denied path, a scope violation, a new credential appearing) and configuration problems (publishing disabled, GitHub not configured, a draft-only or review-PR mode). Everything else is recorded and the post goes out.

Reference: post publication states

StateMeaning
Needs reviewThe draft is preserved after a publish error, or the mode requires review
Awaiting review by designThe post is waiting in a pull request
PublishedThe commit landed on the publish branch
Site deploy failed — not liveThe commit landed, the site's own deploy failed
Deploy status unavailableThe GitHub App cannot read Actions on that repository
Verified liveThe public URL was re-fetched and resolved

Troubleshooting

SymptomCauseFix
The post shows as published but the page 404sThe commit landed and the site's own GitHub Actions deploy failedOpen the drawer, follow Open the failed run, fix the site repo and push
Deploy status reads unavailable with no failed runThe GitHub App installation lacks Actions: ReadGrant that permission for the repository, then wait for the next re-check
Posts stop at a pull requestThe mode is Review PR, or approval mode refused direct pushSet Publish mode to auto-merge or direct push, and approval mode to trusted auto-publish
Nothing publishes, the error mentions GitHubNo valid per-tenant GitHub App credentialThe account owner installs or repairs it on the GitHub tile in Settings → Integrations, then Re-draft or Approve & publish
A post was preserved after a publish errorGitHub returned an error mid-publishApprove & publish re-commits the stored change set at no extra writing cost
A fixed deploy has not cleared the postRe-checks widen over timeWait for the next window; a successful deploy containing the commit clears it automatically