Features

Incidents

When multiple monitors fail at once, you don't need N separate alerts. DeadPing automatically groups related failures into a single incident, reducing alert fatigue and giving you a clear picture of what's happening.

Incidents in DeadPing automatically group related monitor failures into a single event. When multiple monitors go down around the same time, you get one incident notification instead of a flood of individual alerts. Each incident includes a timeline, affected monitors, and postmortem fields. Business plan feature.

Business tier feature. Incidents are available on the Business plan ($39/mo).

What Is an Incident?

An incident is an automatic grouping of monitor failures that occur within a short time window. When your database goes down, it might take out five different cron jobs. Instead of five separate alerts, DeadPing creates one incident containing all five failures.

How Grouping Works

DeadPing uses a 5-minute time window for grouping. When a monitor fails:

  1. DeadPing checks if there is an open incident within the last 5 minutes
  2. If yes, the failing monitor is added to the existing incident
  3. If no, a new incident is created with this monitor as the first failure

This means that cascading failures caused by a shared dependency (like a database, network, or cloud provider) are grouped into a single incident automatically.

Alert Suppression

Without incidents, N failing monitors produce N × 2 notifications (one “down” and one “recovered” per monitor). With incidents enabled, you get exactly 2 notifications per incident:

  • Incident opened – lists all affected monitors
  • Incident resolved – includes an auto-generated summary

For example, if 10 monitors fail due to a database outage, you get 2 notifications instead of 20.

Auto-Generated Summaries

When all monitors in an incident recover, DeadPing automatically generates a summary that includes:

  • Total incident duration
  • Number of affected monitors
  • Per-monitor downtime breakdown
  • Timeline of failures and recoveries

Postmortem Editing

After an incident is resolved, you can add postmortem details directly in the dashboard:

  • Root cause – Document what caused the incident
  • Action items – Track follow-up tasks to prevent recurrence

These fields are stored with the incident and visible to your entire team.

Dashboard UI

The incidents section in the dashboard provides:

  • Incidents list – All incidents sorted by recency, with status badges (open/resolved)
  • Incident detail – Timeline view showing when each monitor failed and recovered
  • Postmortem editor – Add root cause analysis and action items

API

List Incidents

GET /api/incidents

bash
curl -H "X-API-Key: dp_live_..." \
  "https://deadping.io/api/incidents"

Returns an array of incidents for your account, including id, status, started_at, resolved_at, and the list of affected monitor IDs.

Get Incident

GET /api/incidents/:id

bash
curl -H "X-API-Key: dp_live_..." \
  "https://deadping.io/api/incidents/INCIDENT_ID"

Returns the full incident detail including timeline, affected monitors with per-monitor downtime, summary, and postmortem fields.

Update Incident (Postmortem)

PATCH /api/incidents/:id

bash
curl -X PATCH "https://deadping.io/api/incidents/INCIDENT_ID" \
  -H "X-API-Key: dp_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "root_cause": "PostgreSQL ran out of connections due to connection pool misconfiguration",
    "action_items": [
      "Increase max_connections to 200",
      "Add PgBouncer for connection pooling",
      "Set up connection count alerting"
    ]
  }'