Understand Publish Logs

Publish Logs record what happened each time content is published. When a publish succeeds, the log confirms it; when one fails, the log is where you find out why. This page explains what Publish Logs show.

Who this is for

Workspace Owners and Admins, who can view the workspace Publish Logs. The logs are read-only.

What a publish job includes

Publishing a content item runs through several stages, and Publish Logs capture each one:

• Validation (preflight) — Acrosite checks the content and its files are ready to commit.
• Commit plan — Acrosite prepares the exact files and paths it will write.
• GitHub commit — Acrosite commits the content (and any images) to your repository, and records the commit reference.
• Deployment trigger — Acrosite sends your deployment trigger.
• Worker and retry — for scheduled or retried publishes, the background worker's activity is recorded too.

Each job has an overall status, such as pending, running, succeeded, failed, cancelled, or stale.

Where to find Publish Logs

Open your workspace and go to Publish Logs (under the workspace logs area). You can filter and page through entries, and open a single entry to see its details.

How to read a failed publish

When a job fails, open its log entry and look at the stage that failed and the error summary. Common patterns:

• A failure at the GitHub commit stage usually points to a connection or branch problem.
• A failure at the deployment trigger stage points to a deploy hook problem; see also Deployment Logs.
• A validation failure means something about the content or its files needs fixing first.

From there, follow Troubleshoot publishing failures.

Retention

Publish Logs are kept for a period that depends on your plan, then older entries are cleaned up. The retention window is shown on the Publish Logs page. See Billing, trial, and plan limits.

Next steps

• Understand Deployment Logs for the deployment side.
• Troubleshoot publishing failures to resolve a failed job.