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 are suppressed unless an announcement rule explicitly allows private incidents.
• 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.

Paging the incident response team

Declaring or accepting an incident does not page every member of the organization. Paging is driven by the incident response settings and their escalation policies:

• Choose a commander policy for the Incident Commander role and, optionally, an ownership policy for the team that owns the affected service.
• Each policy can target a user or the current responder on an on-call schedule. A schedule target pages the person currently on duty; it does not page every historical schedule member.
• Ownership paging is enabled separately. Test and retrospective incidents are not paged unless their corresponding settings are enabled.
• A live incident declared directly in Active status starts paging immediately. A declaration in Triage waits until it is accepted; accepting it moves the incident into the active response path and starts the configured paging activation.

The incident response panel shows each activation, target, attempt, acknowledgement, and failure. If no policy is configured, or a target was already paged by an Alert Route, the activation records that reason instead of implying that a page was sent. Failed targets can be retried from the incident response view.

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

Under On-Call → Configuration, administrators can tailor what each incident captures. The administration surface 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.