Publish a retrospective to lock its content, generate a public shareable URL, and control who can view it externally.
A retrospective has two states: Draft and Published. Draft is the working document — responders edit, regenerate AI blocks, and collaborate in real time. Publishing marks the retrospective as final, records a publish timestamp, and unlocks a public shareable URL for stakeholders who don’t have a Rootly account.
Publishing is separate from completing the retrospective process. The process moves through progress statuses (not_started → active → completed) as steps get done. Publishing is the document-level action that locks the retrospective content and makes it externally shareable.
Publish from the retrospective document view once the write-up is ready.
1
Open the retrospective
Navigate to the incident, then open the retrospective document from the incident sidebar or the Retrospectives section.
2
Review the draft
Confirm every AI-drafted section has been reviewed, comments have been resolved, and the timeline reflects the final sequence of events. Publishing does not prevent further edits, but the published timestamp marks the moment of first publication.
3
Click Publish
The Publish action moves the document from draft to published, records published_at, and — depending on your workflow configuration — triggers subscriber notifications.
Automate publish-time notifications with a Retrospective Updated workflow filtered on progress_status = completed or a status change to published. See Retrospective Workflows.
A read-only view of the published retrospective document. AI blocks render as static content, comments are hidden, and internal-only metadata is stripped.
Public URLs are gated by three conditions. If any condition fails, the URL returns 404 Not Found — the retrospective never leaks.
The retrospective must be published
Draft retrospectives are not accessible via the public URL. Only documents in the published state resolve; drafts and skipped retrospectives return 404. Unpublishing a retrospective invalidates the public URL immediately.
The parent incident must not be private
If the retrospective’s incident is marked private, the public URL always returns 404 — regardless of publish state. This protects sensitive incidents from being shared externally by accident. See Private Incidents.
The team's retro editor must be enabled
The team owning the incident must have the retrospective editor feature enabled. Teams still on the legacy retrospective view do not expose public URLs.
The public URL is link-based — anyone with the URL can view the document. Rootly does not require authentication or issue per-viewer tokens. Treat the URL like a semi-public artifact: appropriate for customer status pages, cross-team writeups, and external RCAs; not appropriate for confidential incidents.
Unpublishing reverts the retrospective to draft. The public URL stops resolving (404), and the published_at timestamp is cleared. Use unpublish when a retrospective needs corrections after external distribution.
Unpublish does not delete the retrospective — the content stays exactly as it was, just no longer public. Republishing reissues the same slug URL.
Beyond the public URL, Rootly supports exporting the retrospective to external document systems via retrospective workflows. Pre-built workflow templates ship for:
Check three things: the retrospective is in published state (not draft), the parent incident is not marked private, and the team owning the incident has the retrospective editor enabled. If all three are satisfied and the URL still 404s, confirm the workspace subdomain in the URL matches your Rootly workspace.
Stakeholder can see the URL but the page looks empty
The public renderer omits comments, mentions, and internal-only metadata. If the retrospective was published with mostly-empty sections (AI blocks that never ran, unfilled Liquid), the public page reflects that. Unpublish, fill in the missing content, and republish.
I published, but subscriber notifications didn't fire
Publish-time notifications run through Retrospective Updated workflows. Confirm you have a workflow filtered on the appropriate condition (progress_status or publish state) and that the workflow is enabled for the team owning the incident.
How do I invalidate a public URL after sharing externally?
Unpublish the retrospective. The public URL will return 404 immediately. Republishing reuses the same slug — if you need a new URL entirely, rename the retrospective before republishing (renaming regenerates the slug).
No. Publishing marks the retrospective as final for external distribution but does not prevent further edits. Republishing updates the public view.
Can I publish a private incident's retrospective?
You can publish the retrospective internally, but the public URL will always 404 while the incident is marked private. This is a safety guard — private-incident retrospectives cannot be exposed publicly.
Is there an approval workflow before publish?
Approval is not built in as a separate state. Common patterns: require a Reviewer role on the retrospective process to complete a step named “Sign-off”, or gate the publish action with a workflow condition. See Configuring Retrospective Processes.
Can I customize the public URL?
The URL slug is derived from the retrospective title and is not directly editable. To change the slug, rename the retrospective before publishing — the slug regenerates from the new title.
Are public URLs indexed by search engines?
The public renderer sets expires_now and does not add sitemap entries. Search engines generally do not index Rootly public retrospective URLs by default, but this is not a security boundary — treat any URL you share externally as potentially discoverable.