From 17ec508354851d04b6be264b044e429bd2db1908 Mon Sep 17 00:00:00 2001 From: Maximilian Kaske <56969857+mxkaske@users.noreply.github.com> Date: Thu, 22 Oct 2026 10:26:22 +0200 Subject: [PATCH] seo: incident management guides and product page retitle (#2970) * seo: incident management guides and product page retitle The incident management product page sat at position ~23 for "slack incident management", a query Google treats as informational: the SERP is setup guides, not product pages. Add the guide that fits that SERP, a guide for "incident commander" (1.9k/mo, KD 1), and turn the dormant "what is incident management" guide into the hub that links into the product page. The product page itself now targets the commercial terms ("incident management platform/software") instead. * seo: match guide wording to incident behaviour Review pass: notes and pinned messages land on the timeline without an approval card, canceling closes the incident, the dashboard separates Approve from Approve & close, the commander stays editable until close, and reminders fall back to the declarer when there is no commander. --- .../docs/guides/how-to-setup-slack-agent.mdx | 2 +- .../pages/guides/incident-commander.mdx | 223 ++++++++++++++ .../guides/slack-incident-management.mdx | 291 ++++++++++++++++++ .../guides/what-is-incident-management.mdx | 24 +- .../pages/product/incident-management.mdx | 11 +- 5 files changed, 543 insertions(+), 8 deletions(-) create mode 100644 apps/web/src/content/pages/guides/incident-commander.mdx create mode 100644 apps/web/src/content/pages/guides/slack-incident-management.mdx diff --git a/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx b/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx index 22f431a53..8b9938891 100644 --- a/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx +++ b/apps/web/src/content/pages/docs/guides/how-to-setup-slack-agent.mdx @@ -106,7 +106,7 @@ Plan downtime so subscribers are informed in advance. ### 6. Run an incident from Slack -The examples above publish to your status page. An incident is the internal side: a severity, a commander, a timeline and a postmortem, in a Slack channel of its own. +The examples above publish to your status page. An incident is the internal side: a severity, a commander, a timeline and a postmortem, in a Slack channel of its own. For the why and a runbook, see [running incidents in Slack](/guides/slack-incident-management). diff --git a/apps/web/src/content/pages/guides/incident-commander.mdx b/apps/web/src/content/pages/guides/incident-commander.mdx new file mode 100644 index 000000000..e1e0446ba --- /dev/null +++ b/apps/web/src/content/pages/guides/incident-commander.mdx @@ -0,0 +1,223 @@ +--- +title: "Incident Commander" +seo: + title: "What Does an Incident Commander Do? Role, Checklist, Handover" + description: "The incident commander coordinates the response, decides, and communicates. They do not debug. What the role covers, a checklist for the first ten minutes, how to hand over, and how a small team does it without an on-call rotation." +description: "What the incident commander actually does during an outage, what they should refuse to do, a checklist for the first ten minutes, how to hand the role over, and how a three-person team fills it." +author: "openstatus" +publishedAt: "2026-10-22" +category: "fundamentals" +faq: + - question: "Does the incident commander need to be an engineer?" + answer: "No. The commander coordinates, decides and communicates; they do not need to be able to fix the problem. Many teams deliberately pick someone who is not the best-placed debugger, because that person should be debugging. What the commander needs is enough context to judge severity and impact, and the authority to make calls without asking permission." + - question: "Can the incident commander change during an incident?" + answer: "Yes, and for anything longer than a few hours it should. Hand over explicitly: the outgoing commander states the current status, what is known, what is being tried, when the next customer update is due, and who is doing what. The incoming commander confirms in the channel. A handover nobody announced is a gap nobody owns." + - question: "What is the difference between the incident commander and on-call?" + answer: "On-call is who gets paged and starts looking. The incident commander is who runs the response once it is declared. Often it is the same person for the first few minutes, but on-call's job is to fix, and the commander's job is to coordinate. When both are needed at once and only one person is awake, the commander role is the one to hand to the next person who joins." + - question: "Should the incident commander write the status page updates?" + answer: "The commander owns the decision to post and what the update must say. Writing it can be delegated to a communications lead, and on larger incidents it should be. On a small team the commander usually writes it, which is fine as long as writing the update is a scheduled task and not something that happens when there is a quiet moment." + - question: "What does the incident commander do after the incident?" + answer: "Make sure the postmortem happens. The commander has the clearest picture of what was decided and why, so they either write the first draft or review the one the team produces. They also own the handover from incident to action items: who is doing what, by when." +--- + +Every incident has a commander whether you name one or not. If nobody holds the +role, it is whoever is loudest in the channel, and the first decision gets made twice +by two people who did not know the other was deciding. + +Naming one person removes that. The incident commander, usually shortened to IC, is +the single person responsible for how the response is run. Not for fixing the +problem. For running the response. + +## What the incident commander does + +Three jobs, in order of how often they come up: + +**Coordinates.** Knows who is working on what. Pulls people in and sends people away. +Keeps one conversation going instead of three. When two engineers are both about to +roll back the same deploy, the commander is the one who notices. + +**Decides.** Severity. Whether to roll back or roll forward. Whether to page someone +at 3 a.m. Whether the incident is mitigated. When to stop. The commander does not +need to be the one with the best answer; they are the one who makes sure a decision +gets made and that everyone knows what it was. + +**Communicates.** Owns the clock on customer updates. Decides what the status page +says and when. Keeps the rest of the company from walking into the channel to ask +"any update?". Internally, the commander is the person to ask. Externally, the +commander decides what gets said. + +## What the incident commander does not do + +**Debug.** This is the rule that gets broken most. The moment the commander opens a +terminal they stop coordinating, and the response goes back to being a group of +people each solving their own version of the problem. If the commander is the only +one who can fix it, hand the role to someone else and fix it. + +**Find the root cause.** During the incident the goal is to stop the impact. Root +cause is the postmortem's job. A commander who lets the team chase "why" before +service is restored extends the outage. + +**Do everything themselves.** Writing updates, keeping the timeline, paging people +and talking to support are all things the commander is responsible for and none of +them are things the commander has to do personally. On a larger incident, delegate +the writing to a communications lead and the timeline to a scribe. + +## The first ten minutes + +A checklist for the person who just became commander: + +1. **Say so.** "I'm IC for this one." in the channel. Everyone now knows who to ask. +2. **Set the severity.** Use the team's [severity matrix](/guides/incident-severity-matrix), + not a feeling. Severity sets the update cadence and who gets paged. +3. **State what is known in one message.** Symptom, who is affected, since when. + Nothing about cause yet. +4. **Post the first public update.** Within fifteen minutes of detection. "We are + investigating elevated errors on the checkout API. Next update at 10:15." The + [incident communication guide](/guides/incident-communication) has the wording + per stage. +5. **Assign.** One person on the most likely cause, one person watching for the + fix landing, one person on comms if the incident is big enough. Name them. +6. **Set the next checkpoint.** When the team regroups, and when the next customer + update goes out. Put both in the channel. + +Everything after that is a loop: check in, decide, update, repeat, until the impact +stops. + +## Running the incident + +**Keep one place.** One channel. Decisions in the channel, not in direct messages. +If a decision was made on a call, the commander writes it into the channel. + +**Keep the timeline as you go.** The postmortem will be written from it. The +commander does not have to type it; pin the message where someone identified the +cause, the message where the rollback was decided, the message where recovery was +confirmed. Two hours later nobody remembers which came first. + +**Update on schedule, not on news.** "Still investigating, next update in 30 +minutes" is a complete update. Missing a promised update costs more than the outage. + +**Mitigate before you understand.** If a rollback stops the impact, roll back. The +team can find out what was in the deploy after customers can check out again. + +**Call it.** Declaring the incident mitigated, then resolved, is the commander's +call. So is declaring it a false alarm. Make the call explicitly so the team can +stand down. + +## Handing over + +Incidents that run longer than a few hours need a new commander. Tired commanders +make slow decisions. The handover is a message, not a feeling: + +- Current status and severity. +- What is known and what is not. +- What is being tried right now and by whom. +- When the next customer update is due and what it should say. +- Anything promised to anyone, including support and the customer who emailed the + CEO. + +The incoming commander repeats it back in the channel and says "I'm IC now." The +outgoing commander leaves. If they stay in the channel they will keep deciding. + +## On a small team + +Three engineers, no on-call rotation, one of them is asleep. The commander is also +the person fixing it. That is normal and it works, with two adjustments. + +**Separate the hats in time.** Spend the first five minutes as commander: severity, +first public update, next checkpoint. Then fix. Set a timer for the next update so +the commander hat comes back on whether or not the fix is done. + +**Hand off the moment someone else is awake.** The second person to join takes +command, because the first person is already deep in the problem and should stay +there. + +**Let the tooling hold the clock.** Reminders when the incident goes quiet, a drafted +first status report, a timeline built from pinned messages. The fewer things the +commander has to remember, the more of the role one person can carry. + +## Where the commander lives in openstatus + +The commander is a field on the incident, set when you +[declare it](/incident-management#declare-from-slack-or-the-dashboard) from the +dashboard, from Slack or from an agent, and changeable until the incident is closed. +Changing it is recorded on the timeline. Three things depend on it: + +- **Stale reminders.** An incident that goes quiet gets a reminder in its Slack + channel. Without a channel, the reminder is sent as a direct message to the + commander, or else to the person who declared it. +- **The postmortem.** The commander, an owner or an admin approves the drafted + postmortem. From the Slack card, approving also closes the incident; the dashboard + offers **Approve** and **Approve & close** separately. +- **Closing.** A resolved incident is closed by the commander, an owner or an admin. + Canceling a false alarm closes it on the spot. + +The rest of the role is yours. The tooling keeps the record so that the person +coordinating does not also have to be the person remembering. [How incident +management works in openstatus](/incident-management) shows the whole flow from +alert to postmortem, and the [incident management +reference](/docs/reference/incident-management) has the rules. + +## Frequently asked questions + +
+ +No. The commander coordinates, decides and communicates; they do not need to be able +to fix the problem. Many teams deliberately pick someone who is not the best-placed +debugger, because that person should be debugging. What the commander needs is enough +context to judge severity and impact, and the authority to make calls without asking +permission. + +
+ +
+ +Yes, and for anything longer than a few hours it should. Hand over explicitly: the +outgoing commander states the current status, what is known, what is being tried, +when the next customer update is due, and who is doing what. The incoming commander +confirms in the channel. A handover nobody announced is a gap nobody owns. + +
+ +
+ +On-call is who gets paged and starts looking. The incident commander is who runs the +response once it is declared. Often it is the same person for the first few minutes, +but on-call's job is to fix, and the commander's job is to coordinate. When both are +needed at once and only one person is awake, the commander role is the one to hand to +the next person who joins. + +
+ +
+ +The commander owns the decision to post and what the update must say. Writing it can +be delegated to a communications lead, and on larger incidents it should be. On a +small team the commander usually writes it, which is fine as long as writing the +update is a scheduled task and not something that happens when there is a quiet +moment. + +
+ +
+ +Make sure the postmortem happens. The commander has the clearest picture of what was +decided and why, so they either write the first draft or review the one the team +produces. They also own the handover from incident to action items: who is doing +what, by when. + +
+ +--- + +**Openstatus gives the commander one record: the alert, the timeline, the public +update and the postmortem.** Open source. [See how incident management +works](/incident-management) or start with [what incident management +is](/guides/what-is-incident-management). + +Declare your first incident + +--- + +Start free. No credit card required. + +--- diff --git a/apps/web/src/content/pages/guides/slack-incident-management.mdx b/apps/web/src/content/pages/guides/slack-incident-management.mdx new file mode 100644 index 000000000..68ef3f6d1 --- /dev/null +++ b/apps/web/src/content/pages/guides/slack-incident-management.mdx @@ -0,0 +1,291 @@ +--- +title: "Slack Incident Management" +seo: + title: "Slack Incident Management: Setup Guide, Commands and Channels" + description: "How to run incidents in Slack: declare with a slash command, get a channel per incident, pin messages to the timeline, update the status page from the channel and leave with a drafted postmortem." +description: "A setup guide for running incidents in Slack: one channel per incident, slash commands to declare and change status, a timeline built from pinned messages, a public update from the same channel, and a postmortem draft when it is over." +author: "openstatus" +publishedAt: "2026-10-22" +category: "education" +faq: + - question: "Do I need a separate Slack app for incidents?" + answer: "No. The openstatus Slack agent that subscribes channels to a status page is the same app that declares and runs incidents. If you installed it before incident management existed, go to Settings > Integrations and click Reconnect to grant the channel permissions." + - question: "What happens to the channel after the incident?" + answer: "The channel stays open while the incident is open, mitigated or resolved, so the postmortem can be drafted from it. It is archived when the incident is closed or canceled. Archived channels remain searchable in Slack." + - question: "Can I link an existing channel instead of getting a new one?" + answer: "Yes. When you declare from a channel your team is already working in, the bot posts a notice with a Link this channel instead button. Clicking it moves the incident there, pins the card in that channel and archives the inc- channel that was just created." + - question: "Does the bot read the whole channel?" + answer: "When you mention it, the agent reads the 50 messages before your mention, or the 20 before the thread you are in, and can page back further when it needs to. Slack message links in your message are read as well. The postmortem draft uses the incident channel's history. Declaring, changing status and approving the postmortem go through an approval card; a pinned message or a note lands on the timeline straight away, and nothing reaches the status page until you submit the form." + - question: "Can I run incidents without Slack?" + answer: "Yes. Declare, update, resolve and write the postmortem from the dashboard, or through the MCP server from an agent. Slack adds the channel per incident, slash commands, pinning to the timeline and stale reminders on top of the same incident record." +--- + +Most teams already run incidents in Slack. The problem is not Slack. It is that the +incident has no record of its own: the alert lands in one channel, the discussion +happens in a thread, the status page is updated from a browser tab, and two days later +someone reconstructs the timeline from scrollback for the postmortem. + +This guide sets up the other way of doing it: one channel per incident, a slash +command to declare and change status, a timeline that is built from the messages you +pin, a public update posted from the same channel, and a postmortem drafted from all +of it once the incident is resolved. It uses the openstatus Slack agent. Setup takes +about five minutes. + +## Why one channel per incident + +A single `#incidents` channel works until two things go wrong at once. Then the +rollback discussion for the checkout API is interleaved with the DNS problem, the +person who joins late cannot tell which messages belong to which incident, and the +pinned "current status" message is already stale. + +A channel per incident gives you: + +- **A name that says what it is.** `inc-2026-10-22-checkout-api-503s-in-eu` is + findable in Slack search next month. "The thread in #incidents from Tuesday" is not. +- **A topic that is the current state.** Severity and status live in the channel + topic and are kept in sync, so nobody has to scroll to find out whether the incident + is still open. +- **A scope for the record.** Everything in the channel is about this incident, so + the timeline and the postmortem can be built from it instead of from memory. +- **A clean end.** The channel is archived when the incident is closed. It stays + searchable and stops being noise. + +## Setup + +1. In openstatus, go to **Settings** > **Integrations** and click **Add to Slack**. + The Slack agent is available on paid plans. +2. Invite the bot to the channel you declare incidents from, for example + `#incidents`, with `/invite @openstatus`. +3. If you installed the app before incident management existed, click **Reconnect** + in the same settings page. Incident channels need permissions the older install + did not ask for. + +The step-by-step version with screenshots is in [Set up the openstatus Slack +agent](/docs/guides/how-to-setup-slack-agent). + +## Declare an incident + +From any channel the bot is in: + +``` +/openstatus incident declare Checkout API 503s in EU --sev major +``` + +The bot posts an approval card with the title and severity. Nothing exists until +someone approves it. Once approved: + +- The incident is declared with you as the declarer. +- A channel named `inc-YYYY-MM-DD-` is created with the date in UTC. +- You are invited, the topic is set to the severity and status with a link to the + incident, and the incident card is pinned at the top. + +Severity defaults to `major`. The three levels are `critical` for a major outage or +data loss, `major` for significant degradation and `minor` for limited impact. If you +do not have a shared definition of those yet, the [incident severity +matrix](/guides/incident-severity-matrix) is the place to agree on one. + +Run `/openstatus incident declare` without a title to get a form instead, with a +commander, a start time you can set in the past and an existing status report to +link. + +### Already working in a channel? + +If your team opened a channel before anyone declared, declare from there. The bot +posts a notice with **Link this channel instead**. Clicking it moves the incident +into the channel you are in, pins the card there, and archives the `inc-` channel it +just created. The move is recorded on the timeline. + +### Started by a monitor? + +When the incident began with an alert, declare it from the monitor's downtime row in +the dashboard. The start time is filled in from the first failed check, so the +duration counts from when users were affected and not from when someone got around to +declaring. The channel is opened the same way. See [incident management in +openstatus](/incident-management#from-the-monitor-that-caught-it) for how the +monitor, the incident and the status page connect. + +## What the channel gives you + +The pinned card is the control surface for the incident. Its buttons: + +- **Update status** changes the status or severity, or posts an update to the + channel and the timeline. +- **Update status page** publishes a status report linked to the incident, or adds + an update to the one already linked, with an option to notify subscribers. + +Right after the channel is created, the bot also posts a **Create a status report?** +card with a drafted first public update. The draft is built from the incident and +from the channel you declared in. When there is enough evidence it suggests the status +page, the affected components and the time users were first affected. **Create status +report** opens the form filled in. Nothing is published until you review and submit +it. **Not needed** dismisses the card. + +## Keep the timeline from the channel + +The timeline is what the postmortem is written from, so it should hold the decisions +and the facts, not every message. Three ways to put a message on it: + +1. Open the message's **⋯** menu and choose **Add to incident timeline**. +2. React to it with 📌. +3. Write a note directly: + +``` +/openstatus incident note Rolling back the 09:38 edge config deploy. +``` + +A pinned message becomes a timeline note attributed to its author, with a link back +to the Slack message. Thread replies work too. The bot confirms with ✅. + +What is worth pinning: the message that identifies the cause, the decision to roll +back, the moment someone confirms recovery, anything a customer was told outside the +status page. What is not: "looking", "same here", and the forty messages in between. + +## Change the status + +``` +/openstatus incident mitigate Rollback complete in eu-west-1 and eu-west-2. +/openstatus incident resolve +``` + +`cancel` and `reopen` work the same way. The note after the command lands on the +timeline. Each change posts an approval card first, is announced in the channel, and +updates the topic. + +The statuses: `open` while the impact is ongoing, `mitigated` once the impact has +stopped but the cause is not fixed, `resolved` when it is fixed, `canceled` for a +false alarm. Mitigate early and honestly. "The bleeding stopped, we do not yet know +why" is a real state and your customers would rather hear it than wait for the full +fix. + +Outside the incident's channel, name the incident: `/openstatus incident resolve +#12`. `/openstatus incident status` shows where an incident stands and +`/openstatus incident list` shows the open ones. + +### The status page is separate on purpose + +Resolving the incident does not resolve the public status report, and mitigating it +does not post an update. The internal record and the public one keep their own status +and their own wording. That is what lets the team mark the incident mitigated while +the status page still says monitoring. Post the public update with **Update status +page** on the card, in your own words. What to write at each stage is in [incident +communication](/guides/incident-communication). + +## Stale reminders + +An incident that goes quiet gets a reminder in its channel. The threshold depends on +severity: + +| Severity | First reminder after | +| --- | --- | +| `critical` | 1 hour | +| `major` | 4 hours | +| `minor` | 24 hours | + +If it stays quiet, the next reminders come at twice, four times and eight times that +threshold. Without a channel, the reminder is sent as a direct message to the +commander, or to the person who declared the incident. + +This is the fix for the incident that was mitigated on Friday, forgotten over the +weekend, and found still open on Tuesday with no postmortem. + +## Draft the postmortem + +Once the incident is resolved: + +``` +/openstatus incident postmortem +``` + +The agent drafts a blameless postmortem from the incident's fields, the timeline, the +linked status report's updates and the history of the channel. It 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 instead of guessing. + +The draft is posted with a card to approve it. Edit it in the dashboard first if you +want. Approving from the card closes the incident, which freezes it and archives the +channel. The dashboard separates the two: **Approve** keeps the incident open, +**Approve & close** does both. The +whole chain, from the alert through every status change to the approved postmortem, +is in the audit log with the person behind each step. + +## Without Slack + +Everything above has a dashboard equivalent: declare from **Incidents**, from a +monitor's downtime row or from a status report; add notes; change status; draft and +approve the postmortem. Agents get the same tools through the [MCP +server](/docs/reference/mcp-server#incidents), with an approval step before anything +changes. Slack adds the channel, the slash commands, pinning and the reminders on top +of the same record. + +## A runbook you can paste into the channel topic + +``` +1. /openstatus incident declare <title> --sev <critical|major|minor> +2. Approve the "Create a status report?" card, or dismiss it +3. Pin the message that identifies the cause (📌) +4. /openstatus incident mitigate <what stopped the impact> +5. Update status page from the pinned card +6. /openstatus incident resolve +7. /openstatus incident postmortem, then approve +``` + +## Frequently asked questions + +<Details summary="Do I need a separate Slack app for incidents?"> + +No. The openstatus Slack agent that subscribes channels to a status page is the same +app that declares and runs incidents. If you installed it before incident management +existed, go to **Settings** > **Integrations** and click **Reconnect** to grant the +channel permissions. + +</Details> + +<Details summary="What happens to the channel after the incident?"> + +The channel stays open while the incident is open, mitigated or resolved, so the +postmortem can be drafted from it. It is archived when the incident is closed or +canceled. Archived channels remain searchable in Slack. + +</Details> + +<Details summary="Can I link an existing channel instead of getting a new one?"> + +Yes. When you declare from a channel your team is already working in, the bot posts +a notice with **Link this channel instead**. Clicking it moves the incident there, +pins the card in that channel and archives the `inc-` channel that was just created. + +</Details> + +<Details summary="Does the bot read the whole channel?"> + +When you mention it, the agent reads the 50 messages before your mention, or the 20 +before the thread you are in, and can page back further when it needs to. Slack +message links in your message are read as well. The postmortem draft uses the +incident channel's history. Declaring, changing status and approving the postmortem +go through an approval card; a pinned message or a note lands on the timeline +straight away, and nothing reaches the status page until you submit the form. + +</Details> + +<Details summary="Can I run incidents without Slack?"> + +Yes. Declare, update, resolve and write the postmortem from the dashboard, or through +the MCP server from an agent. Slack adds the channel per incident, slash commands, +pinning to the timeline and stale reminders on top of the same incident record. + +</Details> + +--- + +**Openstatus runs the incident next to the monitor that caught it and the status page +that reports it.** Open source. [See how incident management +works](/incident-management), or read the [incident management +reference](/docs/reference/incident-management) for every command and rule. + +<ButtonLink href="https://app.openstatus.dev">Declare your first incident</ButtonLink> + +--- + +Start free. No credit card required. + +--- diff --git a/apps/web/src/content/pages/guides/what-is-incident-management.mdx b/apps/web/src/content/pages/guides/what-is-incident-management.mdx index f451b9891..e9901568e 100644 --- a/apps/web/src/content/pages/guides/what-is-incident-management.mdx +++ b/apps/web/src/content/pages/guides/what-is-incident-management.mdx @@ -1,8 +1,11 @@ --- title: "What Is Incident Management?" +seo: + title: "What Is Incident Management? Lifecycle, Roles and Severity" description: "Incident management is the process teams use to detect, respond to, resolve, and learn from service disruptions. Here's the lifecycle, the roles, the severity model, and what separates teams that handle incidents well from those who don't." author: "openstatus" publishedAt: "2026-05-08" +updatedAt: "2026-10-22" category: "fundamentals" faq: - question: "What is incident management?" @@ -41,6 +44,8 @@ Something is wrong. The signal might come from automated monitoring, a customer Someone formally calls it an incident. This matters because declaration triggers process - paging on-call, opening a war room channel, posting an initial [status page](/guides/what-is-a-status-page) update. Without declaration, you have a vague "something seems off" feeling that nobody owns. +Declaration should also create the record: a title, a severity, a start time and a place where the incident is worked. If your team lives in Slack, that place is a channel per incident - see [running incidents in Slack](/guides/slack-incident-management). + Lower the bar to declare. False positives are cheap. Real incidents that nobody declared for an hour are expensive. ### 3. Response @@ -77,6 +82,8 @@ The single person responsible for coordinating the response. Makes decisions, as The IC is not necessarily the most senior or most technical person. Their job is leadership during the incident: who's doing what, what we know, what we don't, when we'll communicate next. A good IC keeps the response organized when everyone else is in heads-down debugging mode. +The full role, a checklist for the first ten minutes and how to hand it over are in [what an incident commander does](/guides/incident-commander). + ### Communications Lead Drafts and posts status page updates. Coordinates with customer support and PR. Keeps internal stakeholders informed. @@ -108,6 +115,8 @@ A common pitfall: severity inflation. If everything is SEV0, nothing is. Be hone See our [incident severity matrix](/guides/incident-severity-matrix) for a more detailed framework. +Three tiers are enough for most small teams. Openstatus uses `critical` for a major outage or data loss, `major` for significant degradation and `minor` for limited impact, and tracks an incident as `open`, `mitigated` (impact stopped, cause not fixed), `resolved` or `canceled`. The mitigated state is the one worth adding to any model: it lets the team say "the bleeding stopped" before they can say "we know why". + ## Communication During an Incident The cadence: @@ -157,6 +166,17 @@ Then communication happens through your [status page](/guides/what-is-a-status-p The pipeline: monitor → detect → declare → respond → communicate → resolve → learn. Every part has to work. +## What the Tooling Should Give You + +The process above does not need a dedicated tool. It needs four things to exist somewhere, and the problem with doing it by hand is that they end up in four places: + +- **One record per incident.** Title, severity, commander, start time, status. Declared from the alert that caught it so the start time is when users were affected, not when someone noticed. ([From the monitor that caught it](/incident-management#from-the-monitor-that-caught-it)) +- **One place to work it.** For most teams a Slack channel per incident, with the status in the topic and the decisions pinned. ([A Slack channel per incident](/incident-management#a-slack-channel-per-incident)) +- **A timeline that writes itself.** Every status change, note and public update timestamped as it happens, so the postmortem is built from the record and not from memory. ([Internal status, public update](/incident-management#internal-status-public-update)) +- **A postmortem that starts drafted.** From the timeline and the channel, with the unknowns marked as unknown, so the team edits instead of reconstructs. ([A postmortem with a first draft](/incident-management#a-postmortem-with-a-first-draft)) + +That is what [incident management in openstatus](/incident-management) is: those four things next to the monitors and the status page they belong to. + ## The Bottom Line Incident management isn't about preventing incidents - they happen to everyone. It's about handling them well when they do. Fast detection, organized response, honest communication, blameless learning. @@ -179,7 +199,7 @@ Detection (something is wrong), declaration (someone calls it an incident), resp <Details summary="What's an incident commander?"> -The incident commander is the single person responsible for coordinating the response - making decisions, assigning tasks, and keeping the team focused. They are not necessarily the most technical person on the call. Their job is leadership during the incident: who's doing what, what we know, when we'll update customers, when to escalate. +The incident commander is the single person responsible for coordinating the response - making decisions, assigning tasks, and keeping the team focused. They are not necessarily the most technical person on the call. Their job is leadership during the incident: who's doing what, what we know, when we'll update customers, when to escalate. See [what an incident commander does](/guides/incident-commander). </Details> @@ -221,7 +241,7 @@ A postmortem that focuses on systems, processes, and contributing factors rather --- -**OpenStatus combines monitoring and status pages so detection and communication live in one place.** Open-source, with on-call alerting and incident management built in. +**Openstatus combines monitoring, status pages and incident management so detection, response and communication live in one place.** Open source. [See how incident management works](/incident-management). <ButtonLink href="https://app.openstatus.dev">Try openstatus free</ButtonLink> diff --git a/apps/web/src/content/pages/product/incident-management.mdx b/apps/web/src/content/pages/product/incident-management.mdx index 53fbd212f..3a44b504a 100644 --- a/apps/web/src/content/pages/product/incident-management.mdx +++ b/apps/web/src/content/pages/product/incident-management.mdx @@ -1,11 +1,11 @@ --- title: "Incident Management" seo: - title: "Incident Management — Slack Channels, Timeline, Postmortems" - description: "Open source incident management next to your monitors and status page. Declare from Slack, get a channel per incident, keep a timeline and draft the postmortem." + title: "Incident Management Platform — Slack, Timeline, Postmortems" + 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." hero: "Incident management for small teams" publishedAt: "2026-10-05" -updatedAt: "2026-10-05" +updatedAt: "2026-10-22" author: "Maximilian Kaske" description: "Declare an incident from Slack or the dashboard, run it in its own channel, keep one timeline and leave with a postmortem. Next to the monitors and the status page it belongs to." category: "Product" @@ -76,7 +76,7 @@ Every status change, note and public update is timestamped as it happens. The po <Grid variant="borderless" sticky> <div> -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, a start time you can set in the past and an open status report to link. +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) @@ -117,6 +117,7 @@ Already working in another channel? Link it instead, and the new one is archived 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) @@ -235,7 +236,7 @@ Every one of those steps is in the audit log with the person behind it, whicheve <Details summary="What is incident management?" headingLevel={3}> -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. +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). </Details> -- 2.54.0