Teams need to know what happened.
After publishing starts, teams should be able to see whether validation, GitHub commit, and deployment trigger steps succeeded.
Feature · Publish LogsPublishing observability center
See exactly what happened when content published.
Acrosite records publish attempts, generated file paths, GitHub commit status, Commit SHA, deployment trigger results, safe failure reasons, and recovery context in role-aware Publish Logs.
Publish attemptsCommit SHASafe failure reasonsDeployment trigger resultsRole-aware visibility
The publishing visibility problem
Publishing should not disappear into the background.
Once a publish starts, it either reaches the repository and triggers a deployment — or it stops somewhere along the way. Without a record of each attempt, teams are left guessing what happened, why it failed, and where it can be picked back up.
Failures need readable reasons.
A failed publish should not leave users guessing. Safe failure messages should point toward what needs attention.
Commit details matter.
Git-backed publishing needs traceability through file paths, branches, commit messages, and Commit SHA records.
Deployment triggers can fail separately.
A GitHub commit can succeed while the deployment trigger fails, so logs need to preserve partial-success context.
Not every role should see technical details.
Developers and Admins may need technical context, while Authors or Client Reviewers should only see simple status where relevant.
Secrets must never appear in logs.
Logs should help teams recover without exposing tokens, provider payloads, hook URLs, or internal stack traces.
Log inspector
One place to inspect publish attempts.
The Publish Log Inspector lists every publishing attempt with its status, stage, mode, timing, Commit SHA, and deployment trigger result. Filter by what matters, scan the run that needs attention, and open it to see safe details — no dangerous controls in the workspace-wide list.
Local SEO GuideSucceededDeployment triggered09:01 · 6.2s
FAQ: Pricing QuestionsPartialDeployment trigger failed08:44 · 5.1s
Dental Implants CostFailedValidation08:30 · 1.3s
Emergency Plumbing AustinRunningGitHub commit08:29 · —
Product UpdateCancelledCancelled before start08:10 · —
About Page UpdateSucceededDeployment triggered07:52 · 5.8s
Local SEO GuideBlog Post · acme-project · Run #4821
Summary
StatusSucceeded
ModeScheduled
Started → Completed09:01 → 09:01
Attempts1
Output
File pathcontent/posts/local-seo-guide.mdx
Branchmain
Commit SHA9f3a2c1
Deployment trigger
ProviderVercel
ResultAccepted
View deployment log
Secrets, hook URLs, tokens, provider payloads, and stack traces are never shown.
The workspace-wide list is read-only — recovery actions live on the surfaces where they are safe and authorized.Open full Publish Log Inspector
Log details
Open a log to see the safe details.
Publish Logs show enough context to understand the attempt — summary, output, deployment trigger, and failure details — without exposing secrets or raw provider payloads. Every drawer ends with the same promise about what is never shown.
Dental Implants CostPage · acme-project · Run #4818
Summary
StatusFailed
ModeScheduled
Started → Completed08:30 → 08:30
Attempt count2
Output
File pathcontent/pages/dental-implants-cost.mdx
Branchmain
Commit SHAnot committed
Deployment trigger
ProviderVercel
ResultNot reached
Failure details
Validation ErrorA required field is missing. Open the content item and complete the required fields before publishing again.Internal reference · PL-4818-VAL
Open contentView recovery path
Secrets, hook URLs, tokens, provider payloads, and stack traces are never shown.
Publish stages
Follow each publish attempt by stage.
Each publish attempt can move through validation, output generation, GitHub commit, deployment trigger, and a final status. Reading an attempt stage by stage shows exactly where it stopped — and whether the result is Succeeded, Failed, or Partial.
This attempt resolves to Partial.
Validation, output, and GitHub commit succeeded — the Commit SHA is saved — but the deployment trigger failed. The log preserves both outcomes so the team can retry the deployment trigger where safe, without recommitting content. This is observability for one attempt, not the product workflow.
Failure clarity
Readable failure categories without leaking internals.
Publish Logs translate failures into a small set of useful categories, each paired with a safe, user-readable message that points toward the next step. The internal detail stays internal — what teams see is what they can act on.
Validation Error
VALIDATION_ERROR
Required fields, required Custom Fields, slug, or readiness checks need attention.
“A required field is missing. Complete the content item before publishing again.”
Media Error
MEDIA_ERROR
An image or media reference needs upload, replacement, or validation.
“A referenced image could not be found. Upload or reselect the media, then retry.”
GitHub Error
GITHUB_ERROR
Repository, branch, path, permission, or file conflict needs attention.
“The repository connection needs a check. Open project integration settings to reconnect.”
Deployment Error
DEPLOYMENT_ERROR
The GitHub commit succeeded, but the configured deployment trigger failed or was rejected.
“The deployment trigger failed. The Commit SHA is saved — retry the deployment trigger where safe.”
Subscription Error
SUBSCRIPTION_ERROR
Publishing was blocked because trial or subscription state did not allow publishing.
“Publishing is blocked by the current plan state. Review the subscription to continue.”
Permission Error
PERMISSION_ERROR
The actor or job did not have permission to continue.
“This action was not permitted for the current role. Check scope with an Admin.”
Lock Error
LOCK_ERROR
A previous publish job is still running, or a stale lock needs to clear before this attempt can continue.
“A publish job is already in progress for this item. This attempt continues once the active or stale lock clears.”
Content Path Error
CONTENT_PATH_ERROR
The generated file path or frontmatter could not be prepared from the configured content paths.
“The generated file path needs attention. Check the content path configuration for this content type.”
Internal Error
INTERNAL_ERROR
Something unexpected happened. The user sees a safe message while internal details stay protected.
“Something went wrong on our side. Support can inspect a safe internal reference — no secrets exposed.”
Commit and trigger visibility
See the GitHub commit and deployment trigger result together.
Acrosite preserves GitHub commit information and deployment trigger results side by side, so teams can understand whether content reached the repository and whether the deployment trigger was accepted — two outcomes that do not always agree.
GitHub commitSucceeded
Repositoryclient-site
Branchmain
File pathcontent/posts/local-seo-guide.mdx
Commit messagePublish: Local SEO Guide
Commit SHA9f3a2c1
StatusSucceeded
Deployment triggerAccepted
ProviderVercel
Trigger profileconfigured
ResultAccepted
Time09:01
Deployment logView
GitHub commit: Succeeded→Deployment trigger: FailedRecovery path: Retry deployment trigger where safe — without recommitting content.
Role-aware visibility
Show the right level of detail to the right roles.
Publish Logs are useful because they are scoped. Owners, Admins, Managers, Developers, Editors, Authors, Viewers, and Client Reviewers should not all see the same technical details — the matrix below shows where detail is full, summarized, or hidden.
Workspace Owner / AdminPublish logs across the workspace and project scope.
ManagerScoped logs and publishing status within their scope.
DeveloperTechnical detail for troubleshooting — GitHub path, branch, commit status, safe categories.
Editor / AuthorStatus summaries for assigned or permitted content where allowed.
ViewerRead-only visibility if allowed by scope.
Client ReviewerNo technical publish logs — only simple published status or URL where assigned and allowed.
Recovery visibility
Know where recovery can happen.
Publish Logs help users understand what can be fixed and where to continue. Some recovery actions happen from content, publishing queues, project setup, or admin support — not necessarily inside the workspace-wide log list. The log points the way; the action lives where it is safe.
1
Fix content
For validation or Custom Field errors, open the content item and complete what is missing.
Open content item2
Fix media
For media errors, upload, replace, or reselect the referenced media.
Open media3
Reconnect GitHub
For GitHub connection or permission errors, open project integration settings.
Open project setup4
Retry publish
For failed publish attempts, authorized users can retry from the appropriate publishing surface where supported.
View related job5
Retry deployment trigger
If the GitHub commit succeeded but the deployment trigger failed, deployment-only retry can happen where safe — without recommitting content.
View deployment log6
Contact support
For platform or internal errors, support can inspect safe internal references without exposing secrets.
Open supportLog scope
View logs where the work happens.
Publish Logs are useful from workspace, project, and content contexts depending on the user’s role and scope — and a publish attempt can link out to its related deployment trigger history when one exists.
Workspace Publish Logs
View publishing activity across accessible projects.
Project Publish Logs
Inspect publish attempts for one connected website project.
Content Item Logs
Understand the publish history for one Post, Page, or Custom Content Type item.
Deployment Logs
Open deployment trigger history when a publish attempt links to a deployment trigger result.
Clear boundaries
What Publish Logs mean in Acrosite.
A focused observability layer over publish attempts — with deliberate edges. Here is what Publish Logs are, and what they do not try to be.
Publish Logs are
- Records of publishing attempts
- Status and stage visibility
- Generated file path records
- GitHub commit status
- Commit SHA records
- Deployment trigger results
- Safe failure messages
- Role-aware visibility
- Recovery context
- Links to related deployment logs
Publish Logs are not
- Raw provider payload storage for users
- A place to expose deployment hook URLs
- A place to expose tokens or secrets
- Full deployment lifecycle tracking
- A generic analytics dashboard
- A dangerous retry / delete / export control center
- A replacement for audit logs
- A guarantee that provider builds completed
Setup checklist
What you need before Publish Logs become useful.
A short path from an empty project to a stream of safe, role-aware publish records — most of it falls into place the first time you publish.
1
Content
Create a Post, Page, or Custom Content Type item.
2
GitHub connection
Connect the project repository and branch through the GitHub App.
3
Content paths
Configure where generated Markdown/MDX files should be written.
4
Deployment trigger profile
Choose Manual / No Automatic Deployment or configure a supported trigger profile.
5
Publish action
Use Publish Now, Scheduled Publishing, Retry Publish, or a publish worker.
6
Role access
Make sure the right Team Members can view the relevant logs within their scope.
Publish Logs FAQ
Questions about publish observability.
What a log records, where the Commit SHA lives, how partial failures and recovery work, who can see what, and how Publish Logs relate to Deployment and audit logs.
Open documentationA Publish Log records a publishing attempt, including status, mode, timing, generated file path, GitHub commit status, Commit SHA where available, deployment trigger result, safe failure reason, and related metadata.
Yes. When a GitHub commit succeeds, Acrosite stores the Commit SHA so authorized users can trace what was committed.
No. Publish Logs record the deployment trigger request and the provider's response — results such as triggered, failed, manual selected, or not configured. They do not confirm that a provider build finished.
The log preserves the Commit SHA, shows the deployment trigger failure, and points to a safe recovery path such as deployment-trigger retry where supported.
Publish Log visibility depends on role and scope. Owners and Admins can see broader logs, Developers can see technical details where allowed, Managers can see scoped logs, and Client Reviewers cannot see technical publish logs.
No. Publish Logs should not expose GitHub tokens, deploy hook URLs, provider payloads, custom header values, stack traces, cookies, environment variables, or other secrets.
Publish Logs show recovery context. Actual retry actions only appear where supported and authorized, such as appropriate publishing or recovery surfaces. Workspace-wide logs avoid dangerous direct retry, export, or cleanup controls.
Yes. Failed logs show safe error categories and user-readable messages so the team can understand whether to fix content, media, GitHub setup, deployment trigger setup, subscription state, or permissions.
Publish Logs track the full publish attempt. Deployment Logs focus on deployment trigger requests and results. A Publish Log may link to a related Deployment Log.
No. Publish Logs are publishing-specific observability records. Audit logs track important product and access changes more broadly.
Start here
Make every publish attempt visible.
Registration is coming soon. Contact us to talk through your publishing workflow, or read the docs to see how Acrosite works.
Registration opening soonPublish LogsCommit SHASafe errorsDeployment triggers