Skip to main content
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_startedactivecompleted) as steps get done. Publishing is the document-level action that locks the retrospective content and makes it externally shareable.

Publish a Retrospective

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.

The Public Shareable URL

Once a retrospective is published, Rootly generates a public URL that stakeholders outside your workspace can open without a Rootly account.
https://<your-workspace>.rootly.com/retrospective_documents/<slug>
Derived from the retrospective title. The slug is stable across edits.
A read-only view of the published retrospective document. AI blocks render as static content, comments are hidden, and internal-only metadata is stripped.

Access Control

Public URLs are gated by three conditions. If any condition fails, the URL returns 404 Not Found — the retrospective never leaks.
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.
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 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

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.

Exporting to External Documents

Beyond the public URL, Rootly supports exporting the retrospective to external document systems via retrospective workflows. Pre-built workflow templates ship for:
  • Google Docs
  • Confluence
  • Notion
  • Coda
  • Dropbox Paper
  • Quip
  • SharePoint / Word
Configure these under Retrospective Workflows and choose the template that matches your integration. See Configuring Templates → Apply Templates Through Integrations.

Troubleshooting

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.
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.
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.
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).

Frequently Asked Questions

No. Publishing marks the retrospective as final for external distribution but does not prevent further edits. Republishing updates the public view.
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.
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.
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.
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.