---
title: "Incident Management Platform — Slack, Timeline, Postmortems"
url: "https://www.openstatus.dev/incident-management"
date: "2026-10-05"
updated: "2026-10-22"
author: "Maximilian Kaske"
description: "Open source incident management software next to your monitors and status page. Declare from Slack, get a channel per incident, keep one timeline, update the status page and draft the postmortem."
category: "Product"
---
[Declare your first incident](https://app.openstatus.dev)
[Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)
Free to start. Try Starter free for 14 days, no card needed. Paid plans from $30/mo.
The incident page for "Checkout API 503s in EU" at the fictional Pied Piper: severity Major, status Resolved, commander Gilfoyle, duration 55m, and a timeline from Declared at 09:43 through a note pinned in Slack, the linked status report, Mitigated at 10:14 and Resolved at 10:36 to the approved postmortem at 11:20.
## Trusted by teams who ship transparency
[Cal.com](https://status.cal.com), [Twenty](/customers/twenty), [Documenso](https://status.documenso.com), [Traefik](/customers/traefik), [Passbolt](https://passboltuptime.com), [Hanko](https://status.hanko.io), [WhiteBIT](https://status.whitebit.com), [Superwall](https://status.superwall.com), [OpenPanel](https://status.openpanel.dev), [Probo](https://probostatus.com), [Roundtable](https://roundtable.eu), [Smplrspace](https://status.smplrspace.com)
## Why run incidents here
**It starts where the alert lands**
The monitor that caught the failure, the incident and the status page live in one workspace. Nothing is copied between tools while the Checkout API is down.
**Internal and public stay apart**
The team works with severities, notes and a commander. Customers read a [status report](/status-page) in your words. The two are linked, never mixed.
**The record writes itself**
Every status change, note and public update is timestamped as it happens. The postmortem and the [audit trail](/use-case/incident-records) are built from it, not from memory.
## Declare from Slack or the dashboard
Run `/openstatus incident declare` with a title and a severity, approve the card, and the incident exists. The dashboard has the same form, with a [commander](/guides/incident-commander), a start time you can set in the past and an open status report to link.
- [Set up the Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Status report reference](/docs/reference/status-report)
Gilfoyle runs `/openstatus incident declare Checkout API 503s in EU --sev major` in #incidents at 09:43. The openstatus app posts an approval card with the title and severity, then confirms the incident is declared and that a dedicated channel was opened with Gilfoyle invited.
## A Slack channel per incident
The incident's own Slack channel, named inc-, the date and checkout-api-503s-in-eu. The pinned card shows severity Major and status Open. Gilfoyle's 09:49 message, "Edge config deploy at 09:38 changed EU routing. Rolling back.", carries a pin reaction and a check mark from the app: it is now a note on the timeline. A reminder follows after 4 hours without an update.
Every incident gets a channel with the severity and status in its topic and the incident card pinned on top. Add any message to the timeline from its ⋯ menu or with a 📌 reaction, with a link back to Slack.
Already working in another channel? Link it instead, and the new one is archived. The channel also gets a drafted first status report, with the affected components and when the problem started, ready to publish in one click.
If the incident goes quiet, the channel gets a reminder: after one hour for critical, four for major and a day for minor.
- [Running incidents in Slack](/guides/slack-incident-management)
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Notification channels](/docs/reference/notification)
## From the monitor that caught it
When a monitor goes down, declare the incident from its downtime row and the start time is already filled in. The duration counts from when the impact began, not from when someone got around to declaring it.
- [Uptime monitoring](/uptime-monitoring)
- [Response logs and retention](/docs/concept/response-logs-and-retention)
The Slack alert that started it at 09:41: Checkout API returned 503 from lhr, ams, cdg and koyeb_fra at 4,388 ms, with 4 of 6 regions failing the status-code assertion.
## Internal status, public update
At 10:14 Gilfoyle runs `/openstatus incident mitigate Rollback complete in eu-west-1 and eu-west-2.` in the incident channel and the app confirms the incident is now mitigated. Below it, the linked status report "Elevated errors on Checkout API" reads Monitoring, with its own public message and 1,337 subscribers notified.
Mitigate, resolve, cancel or reopen from the channel or the dashboard, with a note that lands on the timeline. The linked status report keeps its own status and wording, and you post the public update from the same page.
- [Status page](/status-page)
- [Subscriptions](/docs/reference/subscriber)
## A postmortem with a first draft
Once the incident is resolved, the agent drafts a blameless postmortem from the timeline, the public updates and the channel history. Where it has no facts it says so instead of guessing.
Edit it in markdown, approve it, and close the incident.
- [Slack agent](/docs/guides/how-to-setup-slack-agent)
- [Incident records for audits](/use-case/incident-records)
The postmortem draft, written by the agent, in seven sections: summary, impact (55m, from 09:41 to 10:36 UTC, Europe only), a UTC timeline from Declared to Resolved, root cause (the 09:38 edge config deploy), what went well, what went wrong, and two action items as a checklist. Buttons to approve it or draft again with the agent.
## For agents, with a paper trail
The audit log for the same incident, with the newest entry at the top. From oldest to newest: monitor.alert at 09:41:12, incident.create at 09:43:08 by gilfoyle@piedpiper.dev via Slack, the status report and its updates, incident.update to mitigated and resolved, and the postmortem created by the agent and approved at 11:20:48.
The MCP server and the Slack agent share the incident tools: declare, update, change status, add a note, draft the postmortem. Anything that changes state asks for approval first.
Every one of those steps is in the audit log with the person behind it, whichever surface they used.
- [MCP server](/tooling/mcp-server)
- [Connect openstatus to your agent](/docs/guides/how-to-connect-openstatus-to-your-agent)
## Get started
[Declare your first incident](https://app.openstatus.dev)
Free to start. Try Starter free for 14 days, no card needed. Paid plans from $30/mo.
## Frequently asked questions
What is incident management?
Incident management is how a team responds when something breaks: someone declares the incident, one person takes command, the team works the problem in one place, customers are kept informed, and afterwards a postmortem records what happened and what changes. Openstatus keeps the declaration, the timeline, the public status report and the postmortem in one record. The longer version is in [what is incident management](/guides/what-is-incident-management).
What is the difference between an incident and a status report?
An incident is internal: severity, commander, timeline notes and the postmortem are for your team. A status report is public: it is what customers read on your status page and receive as a subscriber. You link the two, and each keeps its own status, so the team can mark an incident mitigated while the status report still says monitoring.
Do I need Slack to manage incidents?
No. You can declare, update, resolve and write the postmortem from the dashboard. On Starter and above the agent drafts the postmortem for you. Connecting Slack adds the channel per incident, slash commands, pinning messages to the timeline and stale-incident reminders, and the channel history becomes part of the postmortem draft.
How does the postmortem draft work?
Once an incident is resolved, the agent drafts a blameless postmortem from the incident's fields, its timeline, the public status report updates and the history of the incident's Slack channel. The draft has seven sections: summary, impact, timeline, root cause, what went well, what went wrong and action items. Where it has no facts it says what is unknown. You edit the draft, approve it and close the incident.
Which severities and statuses are there?
Three severities: critical for a major outage or data loss, major for significant degradation, and minor for limited impact. An incident is open, mitigated, resolved or canceled. Closing an incident freezes it: status, severity, commander and notes can no longer change.
Can an AI agent run an incident?
Yes. The MCP server and the Slack agent share the same incident tools: declare, update, change status, add a note, draft and approve the postmortem. Every action that changes something asks for approval first and is written to the audit log with the person behind it.