Incidents & Postmortems

Use a native incident when a problem needs coordinated response rather than a single responder working an alert. An incident adds severity, responder roles, source links, communication, and a shared evidence-preserving timeline on top of any on-call alerts it links.

Declare an incident

There are two ways to open an incident, and both use the same declaration form:

• Standalone — from On-Call → Incidents, choose Declare incident. Use this when opening an incident directly rather than from a page.
• From an alert — on an on-call alert, choose Declare Incident. The form is prefilled from the alert, and the alert is linked to the new incident automatically.

Every declaration captures a title, an optional summary and description, a severity from SEV-0 through SEV-4, and an initial status:

• Triage while you confirm whether it is a real incident
• Active once it is confirmed and being worked

Each incident is numbered in declaration order within your organization and referred to by that number everywhere: INC-12 in the list, the incident header, Slack channel names and announcement cards. Typing the reference into the incident URL, /on-call/incidents/INC-12 or just /on-call/incidents/12, opens the incident.

Modes

The mode records what kind of incident this is:

Visibility

Visibility classifies an incident's intended audience:

• Organization — classified for an organization-wide audience.
• Private — restricted to authorized administrators, responders, and participants. Shared Slack announcements skip private incidents unless the announcement includes them.
• Public — classified as shareable beyond your organization.

Visibility is enforced on incident reads and Slack actions. A public classification is not an unauthenticated share link; a public share surface is not enabled.

Responder coordination

On an incident's Responders panel, you can see who is doing what and manage membership:

• Roles such as Incident Commander or Communications Lead can be claimed by yourself, assigned to a teammate, unassigned, or handed over with a handover note.
• Participants are actively working the incident; observers are following along. Members can join, observe, leave, or be removed.

Role assignments and membership changes use optimistic concurrency, so simultaneous edits are detected rather than silently overwriting each other.

Response rules

Response rules decide what happens when an incident becomes active: when it is declared directly in Active status, or accepted from Triage. Declaring an incident in Triage runs nothing until it is accepted. Each rule is a workflow, and its workflow is what pages responders, opens a channel, or assigns roles. Automatic announcements don't depend on the rule; see Incident channels and shared announcements.

• Custom rules are read top to bottom. Only the first enabled rule whose entry conditions match the incident runs. The rest are not reached.
• The default rule is always last and always on. It runs when no custom rule matches, so it has no entry conditions. Out of the box it pages the owning team when the incident has one and makes whoever acknowledges that page Incident Commander, then creates the incident's Slack channel and posts the announcement. The channel doesn't wait for the acknowledgement. If nobody acknowledges within an hour, or the incident has no owning team, the role stays open for someone to claim. Without Slack connected, the channel and announcement steps are skipped and the rest still run. Edit it like any other rule; to fill the role from a commander rotation instead, set the commander step to Whoever is on call and choose the schedule.

Manage the rules under Settings → Incident response → Configuration → Response rules:

1. Select New response rule and choose a template, such as paging the owning team, opening a channel and assigning roles, or paging by severity. The rule is created turned off, just above the default rule, and opens on the Workflows canvas.
2. On the canvas, select the trigger and set the rule's Entry conditions: the incidents it responds to, by severity, priority, incident type, owning team, visibility, a custom field, or working hours. Then edit its steps and publish it.
3. Back in Response rules, turn the rule on. A rule has to be published before it can be turned on.
4. Move rules up or down to change which one claims an incident first. Edit in Workflows opens a rule's workflow again; the list marks a rule whose latest edits are not published yet.

Deleting a custom rule also deletes its workflow and that workflow's runs, so a rule can't be deleted while one of its runs is still responding to an incident. Each rule's workflow is also listed on the Workflows page, but its order and on/off are set here.

To check which rule would answer an incident, use Routing preview below the rules. Describe a sample incident and when it starts, then select Preview routing. The preview lists the rules in order with why each one before the answering rule doesn't match, and steps through what the answering rule's workflow would do. Nothing runs or pages.

Test and retrospective incidents run no response rule unless Page for test incidents or Page for retrospective incidents is on under Workflows & AI → Paging.

The incident page says which rule responded and how many responders it paged, or why no rule ran. View details lists the rule and the workflow version that ran, a link to the run, each paging alert, and any custom rule whose entry conditions could not be checked.

Evidence and timeline

Link supporting evidence on an incident's Sources panel — a runbook or dashboard link, a Slack message, or another message reference. Each linked source shows its type and opens in a new tab, and you can unlink it at any time. On-call alerts are attached through the alert linking flow rather than as manual sources.

The incident timeline is the canonical, evidence-preserving record of what happened. Each event shows:

• Its provenance — the dashboard, Slack, an integration, an import, a workflow, or the system
• Its visibility — organization, participants, private, or public
• When it originally occurred and when it was observed
• Any annotation, whether it was edited, and whether it has been removed

Advanced timeline controls are available per event:

• Annotate — add context without changing the original event.
• Edit — correct the event type, visibility, time, or details.
• Reorder — adjust the order when the recorded sequence needs fixing.
• Remove / Restore — soft-delete an event and bring it back later. Removed events are hidden by default; turn on Show removed to see them.
• Revision history — retain every annotation, edit, reorder, removal, and restore.
• Export JSON — download the full timeline, including removed events, for the record.

You can filter the timeline by event type, provenance, and visibility.

Incident configuration

Open Settings → Incident response → Configuration to tailor what each incident captures. It centralizes response rules, statuses and severities, channels and updates, workflows and AI, post-incident progression, and change history.

• Types group incidents, such as Security or Customer-facing outage, and select which declaration form appears.
• Custom fields are reusable inputs: single- and multi-select, text, number, link, and user, team, service, or catalog-resource references.
• Forms compose those fields for a stage: Declaration, Acceptance, Update, Resolution, or Escalation. Each field has a position, visibility and required state, default value, help text, and optional conditions.
• Roles define responder roles.

When you pick a type while declaring, its configured fields render inline and are validated before the incident is created.

Incident calls

An incident call is attached to a declared incident. Responders can recognize and attach an existing provider link, or Create a Google Meet or Zoom room through an organization-managed host account. They can inspect the current call and history, join or leave it, bookmark it, and end it. If the organization has enabled Moneat Brief call notes, the notes follow responder presence and the current summary is kept up to date in the incident's authorized Slack channel. Call capture follows the organization's configured policy.

Status-page communication

Status-page incidents are linked to a native incident rather than copied into its timeline as unstructured text. An authenticated incident operation can create, update, or resolve a status-page incident, attach its canonical source URL, and record the operation as a timeline event. Reusing the same correlation key is idempotent and returns the existing status-page incident instead of creating a duplicate. Status-page authorization follows the incident's organization and private-responder rules.

Resolve and finish

An active incident can be resolved from its detail page with an optional resolution note. Adding notes and resolving both record events on the timeline.

After resolution, move the incident to Post-incident while the team records follow-ups, decisions, and supporting evidence. The Postmortems queue tracks resolved incidents through draft, review, approval, and publication. The incident workspace can export the postmortem as Markdown, a collaborative document, or a configured destination. The canonical timeline and its revision history can also be exported as JSON. Close the incident only after the response record is complete.

The optional AI assistant can summarize scoped incident evidence and draft response work. It uses the same organization and incident visibility checks as other clients; mutating actions require explicit approval, and private instructions are not exposed in shared incident content. Disable the assistant capability when the workspace should not send incident context to an AI provider.