Skip to content
IncidentBot

Incident response platform demo where you run a sample incident

This simulator runs a complete incident in your browser, on a sample scenario, with no account and no data sent anywhere. You choose the alert, the service, the escalation policy and what time it is, and IncidentBot shows what happens next: who gets paged and how, when escalation kicks in, which Slack channel opens, what the status page says and how the postmortem starts.

Alert source and payload

Choosing a source loads a realistic payload for that tool. Edit it freely: the simulator reads the service name, severity and summary from the fields that source actually uses.

Service and severity

Both are prefilled from the payload. Change them to see how severity changes paging channels and status page wording.

Escalation policy Tier 1, Tier 2, Tier 3

Build up to three tiers. Each tier notifies a target and waits for its timeout before escalating to the next one.

Scenario

When the alert fires

Primary on-call

Resolved Triggered
TimeActorEvent

No events yet. Run the incident to build the timeline.

TimeActorEvent

Affected component

Impact
Time to acknowledge
Time to resolve
Timeline

Postmortem skeleton sections

  1. Summary
  2. Impact
  3. Timeline
  4. Contributing factors
  5. What went well
  6. What could be improved
  7. Action items

Results of this run

Time to acknowledge

People woken up

Escalations used

Policy check

Policy hints

  • This policy has a single tier. At night, an unacknowledged page reaches nobody else. Add a second tier.
  • Your first timeout is 15 minutes. For SEV1 that is a long time before anyone else is paged.
  • The whole team is paged in tier 1. Page one person first and escalate, so fewer people are woken up.

Like what the simulator produced? The same engine runs on your alerts and schedules.

Timeline

Every step of the incident with computed timestamps: alert received, duplicates grouped, incident opened at the chosen severity, each person paged and on which channel (push first, then SMS, then voice depending on severity and time of day), each escalation, the acknowledgement, the Slack channel created and the roles assigned.

  • Alert received
  • Deduplicated
  • Incident opened
  • Paged
  • Escalated
  • Acknowledged
  • Slack channel created
  • Roles assigned

Status page

A draft update your customers would see: the affected component, a status derived from severity and a short customer-facing message.

  • Affected component
  • Degraded performance
  • Partial outage
  • Major outage
  • Investigating

Publish update

Postmortem

The skeleton of the review: a timeline table, the impact window, time to acknowledge and time to resolve from the run, and the sections your team completes.

  • Summary
  • Impact
  • Timeline
  • Contributing factors
  • What went well
  • What could be improved
  • Action items

Metrics

  • Time to acknowledge
  • People woken up
  • Escalations used
  • Policy check

When the policy is weak, the metrics strip says why. Typical hints: a single tier with no fallback at night, a timeout longer than the severity allows, or a policy that wakes the whole team before a lead has seen the alert.

Why run a sample incident on an incident response platform

Evaluating incident response software from a feature list is hard, because the value is in the sequence: what happens in minute one, minute five and minute fifteen. The simulator makes the sequence visible and lets you break it on purpose.

The same rules drive real paging in your workspace, with your schedules from on call scheduling software and your tiers from on call management.

  • Set the primary to not acknowledge at night and watch escalation take over.
  • Drop the policy to one tier and see the hint about missing fallback.
  • Switch severity from SEV3 to SEV1 and compare paging channels and status page wording.
  • Mark the primary out of office and see the override route the page to the right person.

What is different in a real workspace

In your account the alert comes from your monitoring, the people are your engineers and the channel opens in your Slack. Everything else behaves the way you saw here.

  • Real integrations with Datadog, Prometheus Alertmanager, Grafana, CloudWatch, Sentry, email and webhook, described on the incident alerting page.
  • Real paging by mobile push, SMS, voice, email and Slack, independent of Slack availability.
  • A real Slack channel with roles, severity, runbooks and a live timeline, covered on the incident response tools page.
  • Status pages with subscribers and a custom domain, plus postmortems with action items synced to Jira and Linear.

Questions

Does the demo send any alerts or messages?

No. The simulator runs entirely in your browser on a sample scenario. Nothing is paged, nothing is posted to Slack and nothing is stored.

Is the demo a trial plan?

No. It is a simulator, not a plan. IncidentBot is sold as a monthly or annual subscription per responder seat, starting at 49 USD per user per month, or 24 USD billed annually. See pricing.

Can I use my own alert payload?

Yes. Paste a payload from your own monitoring into the payload field. The parser reads the fields each source uses, so a real payload shows you how routing would read it.

Ready to run it on your own alerts

Create your account, connect one monitoring source and page your team for real. The how it works page shows the four setup steps.