Most teams can tell you how their last big outage went. Few can tell you how many incidents they had last quarter, which services caused them, or whether acknowledgement is getting faster. IncidentBot keeps one record per incident from the first alert to the closed postmortem, so the numbers leadership asks for come from the work engineers already do, not from a spreadsheet someone updates on Friday.
| Incident | Service | Severity | Status | Time to resolve |
|---|---|---|---|---|
| INC-2481 | checkout-api | SEV2 | Resolved | 38m 55s |
| INC-2477 | payments-worker | SEV3 | Postmortem in review | 1h 12m |
| INC-2470 | checkout-api | SEV4 | Closed | 2h 05m |
Every incident gets a number, a title, a service, a severity and a status the moment it is opened, whether it started from an alert, from /incident in Slack or from the web app. Everything that happens next is written to the same record.
Find any past incident by service, severity, time range, responder, team, tag or custom field, or by full-text search across titles, notes and timelines. When a similar alert fires again, the responder can open the last incident on that service and see what fixed it.
Because the record captures the moment an alert arrives, the moment someone acknowledges and the moment the incident is resolved, the metrics are measured rather than estimated.
If you want the definitions and the pitfalls of each metric, read our guide to MTTR, mean time to resolve.
Export incidents and their timelines to CSV or pull them through the API into your data warehouse or BI tool. Weekly and monthly reports can be sent by email to stakeholder viewers, who are included on every plan and are not billed.
A general ticketing system can store an incident, but it does not know when the page was acknowledged, who the commander was, or what customers were told. Those facts live in paging and chat, and copying them over by hand is the step that gets skipped. IncidentBot tracks incidents in the same product that pages, coordinates and publishes, so the record is complete without extra work. Action items still go to Jira or Linear, where your team plans work.
Starter includes the incident log and timeline. Team adds custom fields, MTTA and MTTR reports and the on-call load report. Business adds the service catalog with dependencies and ownership, SLA and uptime reporting per service and an audit log. Enterprise adds custom retention and data residency in the US or EU. Compare the plans on the pricing page.
Yes. You can import past incidents from CSV so your reports start with history instead of a blank quarter. Schedules and escalation policies can be imported from Opsgenie and PagerDuty.
Yes. Incidents opened from Slack or the web app are tracked the same way. MTTA is measured from the page or from the moment the incident was opened when there was no alert.
Yes. Incidents marked as not an incident are kept in the log and left out of MTTA and MTTR.
From your monitoring through incident alerting, or from people through Slack incident management. Both routes create the same record.
Start tracking every incident in one record and let the numbers come from the timeline. See a tracked incident from alert to resolution in the incident response platform demo.
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.