An incident moves through five stages: a signal arrives, a person is woken up, a team works the problem, customers are told what is happening, and someone writes down what was learned. IncidentBot covers all five in one product, with one data model and one price per responder seat. This page walks through every feature in the order an incident actually uses it.
| Time | Actor | Event |
|---|---|---|
| 14:02:11 | Datadog | Monitor "checkout-api p95 > 2s" fired |
| 14:02:12 | IncidentBot | Grouped 3 related alerts into INC-2481 |
| 14:02:12 | IncidentBot | Paged primary on-call, Payments (push) |
| 14:07:12 | IncidentBot | No acknowledgement in 5 min, escalated to secondary (SMS, voice) |
| 14:08:40 | Secondary on-call, Payments | Acknowledged |
| 14:09:02 | IncidentBot | Opened #inc-2481-checkout-api-latency, assigned commander |
| 14:12:30 | Comms | Status page: "Degraded performance: Checkout" published |
| 14:41:05 | Commander | Resolved, rollback of release 2026.09.3 |
| 14:41:06 | IncidentBot | Postmortem draft created with 8 timeline events |
Most stacks split this work across separate products for on-call, incident response, status communication and postmortems. Each one has its own login, its own copy of the timeline and its own invoice. In IncidentBot the alert that pages the engineer is the same record that opens the Slack channel, feeds the status page draft and becomes the first row of the postmortem.
IncidentBot receives alerts from Datadog, Prometheus Alertmanager, Grafana, CloudWatch, Sentry, email and any system that can send a webhook. Routing rules read the payload and send each alert to the right service, so a latency alarm on checkout-api pages the payments team and not the whole company.
The details are on the incident alerting page.
Every service has an owner and every owner has a schedule. IncidentBot keeps rotations, overrides and swaps in one calendar, and escalation policies decide who is paged next when nobody acknowledges.
Read more about on call scheduling software and on call management.
Type /incident in Slack and IncidentBot opens a dedicated channel such as #inc-2481-checkout-api-latency, invites the on-call responders and posts the alert context. The team works where it already talks, and every decision lands on the timeline.
See the full workflow on the incident response tools page.
Customers should hear about an outage from you, not from social media. IncidentBot drafts the status update from the incident itself: affected component, impact level and a plain language summary. The communications lead edits it if needed and publishes in one click.
The timeline is captured while the incident runs, so the postmortem starts with facts instead of memory. IncidentBot builds a blameless draft with the timeline, impact window and response times, and the team fills in contributing factors and follow-ups.
The same product fits several ways of running operations. Teams choose the parts they need and grow into the rest.
No. Many teams start with alerting and on-call, then turn on Slack incident channels and the status page once schedules are settled. Everything is included in the plan, so there is nothing extra to buy when you are ready.
A responder seat is a user who can be on call or act on incidents. Stakeholder viewers with read-only access are included in every plan and are not billed. Plan details are on the pricing page.
There is no free plan. Every plan is a monthly or annual subscription. You can try the incident simulator on the demo page without an account.
Run a sample incident in the browser, then create your account and connect your first alert source.
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.