Skip to main content
Manual incidents let you track problems that automated monitors don’t cover — deployment issues, customer-reported outages, or known degradations that haven’t triggered a monitor yet.

​
When to use manual incidents

  • Deployment failures — a bad deploy causes user-facing issues before monitors detect it
  • Customer reports — users report problems that your checks haven’t caught
  • Partial outages — a subset of users is affected but aggregate metrics look healthy
  • Proactive tracking — you know something is wrong and want to start the incident timeline before automation kicks in

​
Creating a manual incident

devhelm incidents create \
  --title "Database latency spike" \
  --severity down

​
Request fields

FieldTypeRequiredDescription
titlestringYesShort summary of the issue
severitystringYesDOWN, DEGRADED, or MAINTENANCE
monitorIdUUIDNoAssociate with a specific monitor
bodystringNoDetailed description or context
Manual incidents have source MANUAL and are immediately set to CONFIRMED status — they skip the watching and trigger phases since a human has already confirmed the problem.
Associating a monitorId links the incident to a specific monitor in the Dashboard and timeline. The monitor’s notification policies will apply for alert routing.

​
Adding updates

Post updates to the incident timeline to keep your team informed: 
devhelm incidents update <incident-id> \
  --body "Identified root cause — connection pool exhaustion" \
  --notify

​
Update fields

FieldTypeRequiredDescription
bodystringYesUpdate message or context
newStatusstringNoTransition to a new status (e.g., RESOLVED)
notifySubscribersbooleanNoSend notification to subscribed channels

​
Resolving a manual incident

devhelm incidents resolve <incident-id> \
  --body "Connection pool limits increased, latency back to normal"
Resolved manual incidents get resolutionReason: MANUAL.

​
Manual vs automated incidents

AspectAutomatedManual
SourceMONITORS, STATUS_DATA, RESOURCE_GROUPMANUAL
Initial statusWATCHING → TRIGGERED → CONFIRMEDCONFIRMED immediately
RecoveryAuto-resolves when recovery policy is metMust be resolved by a user
ReopeningReopens automatically if the monitor fails againDoes not reopen automatically
AlertingRoutes through notification policies based on the monitorRoutes through policies matching the associated monitor, or catch-all policies

​
Next steps

Incident timeline

Track all status changes and updates.

Incidents overview

Understand the full incident lifecycle.

Alerting overview

Configure where manual incident notifications are sent.