Skip to main content
The incident timeline records every state change and update from initial detection through resolution. Use it to understand what happened, when, and who was involved.

​
Viewing the timeline

devhelm incidents get <incident-id>
The response includes the full incident detail plus an ordered list of timeline updates: 
{
  "incident": {
    "id": "a1b2c3d4-...",
    "status": "RESOLVED",
    "severity": "DOWN",
    "source": "MONITORS",
    "startedAt": "2026-04-13T14:23:00Z",
    "confirmedAt": "2026-04-13T14:24:30Z",
    "resolvedAt": "2026-04-13T14:45:00Z"
  },
  "updates": [
    {
      "id": "u1...",
      "oldStatus": null,
      "newStatus": "WATCHING",
      "body": null,
      "createdBy": "SYSTEM",
      "createdAt": "2026-04-13T14:23:00Z"
    },
    {
      "id": "u2...",
      "oldStatus": "WATCHING",
      "newStatus": "CONFIRMED",
      "body": null,
      "createdBy": "SYSTEM",
      "createdAt": "2026-04-13T14:24:30Z"
    },
    {
      "id": "u3...",
      "oldStatus": null,
      "newStatus": null,
      "body": "Investigating — seeing 503s from the upstream API",
      "createdBy": "USER",
      "createdAt": "2026-04-13T14:30:00Z"
    },
    {
      "id": "u4...",
      "oldStatus": "CONFIRMED",
      "newStatus": "RESOLVED",
      "body": "Upstream fixed, all checks passing",
      "createdBy": "USER",
      "createdAt": "2026-04-13T14:45:00Z"
    }
  ]
}

​
Timeline entry fields

Each entry in the updates array represents a single event:
FieldTypeDescription
idUUIDUnique update identifier
incidentIdUUIDParent incident
oldStatusstringPrevious status (null for the initial entry or non-status updates)
newStatusstringNew status (null for informational updates)
bodystringHuman-written message or system-generated description
createdBystringSYSTEM for automated transitions, USER for manual updates
notifySubscribersbooleanWhether this update triggered notifications
createdAtdatetimeWhen the event occurred

​
Status transitions

The lifecycle status moves through a defined set of transitions:
FromToTriggered by
—WATCHINGFirst check failure detected
WATCHINGTRIGGEREDTrigger rule threshold met
TRIGGEREDCONFIRMEDMulti-region confirmation completed
CONFIRMEDRESOLVEDRecovery policy met or manual resolution
RESOLVEDCONFIRMEDReopened — new failures after cooldown expired
Not all transitions appear for every incident. Manual incidents start at CONFIRMED, and some automated incidents may skip WATCHING if confirmation is immediate.

​
Reopening

When a monitor fails again after an incident was resolved and the cooldown period has expired, the incident reopens:
  1. The status moves from RESOLVED back to CONFIRMED
  2. A new timeline entry records the reopen event
  3. The reopenCount on the incident increments
  4. Escalation chains execute based on the policy’s onReopen setting
The cooldown period (configured in the recovery policy) prevents rapid cycling between resolved and confirmed states. During cooldown, new failures do not reopen the incident.

​
Adding manual updates

Post updates to add context for your team without changing the incident status: 
devhelm incidents update <incident-id> \
  --body "Root cause identified — DNS propagation delay" \
  --notify
Set notifySubscribers to true to send the update through the incident’s matched notification policies.

​
Next steps

Incidents overview

Understand statuses, severities, and the full lifecycle.

Incident policies

Configure trigger rules and recovery behavior that drive timeline events.

Escalation chains

Control notification flow and acknowledgment for incident updates.