Skip to main content
By the end of this guide, you’ll understand what happens when a monitor fails, how to investigate an incident, and how to resolve it.
  • At least one monitor running — see First HTTP monitor
  • Familiarity with the Dashboard or CLI

​
When an incident appears

An incident appears in your Dashboard when a monitor’s check failures match its incident policy. Here’s the typical flow:
1

Checks start failing

A monitor’s check returns an error or fails an assertion. DevHelm starts watching the situation.
2

Trigger rule matched

After enough consecutive failures (default: 2), the trigger rule fires. The incident enters TRIGGERED status.
3

Multi-region confirmation

If the monitor runs from multiple regions, DevHelm waits for confirmation from additional regions. This reduces false positives from single-region network issues.
4

Incident confirmed

The incident moves to CONFIRMED. Alerts fire through your notification policies.

​
Investigate the incident

​
View incident details

The incident detail shows:
  • Severity — DOWN, DEGRADED, or MAINTENANCE
  • Affected regions — which probe regions are seeing failures
  • Timeline — every status change and update since detection
  • Trigger rule — which rule fired and why
  • Duration — how long the incident has been active

​
Check the timeline

The incident timeline shows exactly what happened and when:
Look at the updates array — each entry records a status change, user update, or system event with a timestamp.

​
View failing check results

Drill into the monitor’s recent check results to understand what’s failing:
Look for assertion failures, HTTP error codes, timeouts, or connection errors.

​
Resolve the incident

​
Automatic resolution

Most incidents resolve automatically. When the monitor starts passing again:
  1. Consecutive passing checks accumulate (default: 2 required)
  2. Enough regions must be healthy (default: 2)
  3. The incident moves to RESOLVED
  4. A cooldown period prevents immediate reopening (default: 5 minutes)

​
Manual resolution

If you’ve fixed the issue and don’t want to wait for automatic recovery:

​
Add context

Post updates during investigation to keep your team informed. Timeline updates are posted via the API:

​
Key concepts to know

​
Next steps

Incidents overview

Full lifecycle, statuses, severities, and sources.

Incident policies

Customize trigger rules and recovery behavior.

First alert

Get notified when incidents happen.

Incidents guide

Day-to-day incident management workflows.