When something breaks, the hardest part is often not the fix. It is getting the right people into one place, deciding who leads, and keeping track of what was tried. IncidentBot gives every incident a dedicated Slack channel, clear roles, a severity, the right runbook and a timeline that writes itself, so the team spends its attention on the problem.
| Role | Assigned to | Responsibility |
|---|---|---|
| Commander | Secondary on-call, Payments | Runs the incident and makes the calls |
| Comms | Support lead | Status page and stakeholder updates |
| Scribe | IncidentBot | Timeline of messages and decisions |
| Runbook | checkout-api | Attached when the channel opened |
Anyone can type /incident in Slack, or open an incident from an alert in the mobile or web app. IncidentBot creates a dedicated channel named after the incident and the service, for example #inc-2481-checkout-api-latency, and brings in the people who need to be there.
Incidents go better when one person leads, one person talks to the outside world and one person keeps notes. IncidentBot assigns these roles in one command and shows them in the channel summary, so nobody wonders who is in charge.
Severity sets expectations: how fast to respond, who to page, how widely to communicate. IncidentBot uses SEV1 to SEV4 by default, with your own definitions shown in the command so responders pick consistently.
A runbook is only useful if people can find it at 3 a.m. Attach runbooks to services in IncidentBot, and the right one is posted into the channel as soon as the incident opens. Links to dashboards, logs and deploy history sit next to it.
Every page, acknowledgement, role change, severity change and status update is recorded. Messages the team pins or marks with a reaction are added to the timeline with their author and time. After resolution the timeline becomes the core of the incident postmortem, so nobody reconstructs the night from memory.
The communications lead drafts the status page update from inside the incident and publishes it in one click. Stakeholder viewers follow incidents read-only, and they are included in every plan without a seat charge. Business plan teams can run the same process in Microsoft Teams.
Incident response starts with an alert and a page. Routing and deduplication are covered on the incident alerting page, and paging, tiers and acknowledgement on the on call management page. You can watch a whole incident from alert to postmortem in the incident simulator.
Slack is the primary place to coordinate incidents, and Microsoft Teams is supported on the Business plan. Alerting and paging do not depend on either.
Yes. Anyone can type /incident when they notice a problem first, for example from a customer report. The incident is created with the reporter as the first entry on the timeline.
Every plan includes Slack incident channels with /incident and the incident timeline. Incident roles, severity levels, custom fields and runbooks are included in Team and above. See pricing.
Create your account, install the Slack app and open your first incident with /incident.
Your work email and your team size. That is all we need to set up the account.
One price per seat for alerts, on-call, Slack incidents, status page and postmortems.