Skip to main content
Status Data incidents represent problems reported by external services in the catalog. These are vendor-reported outages and degradations — distinct from your own monitor-generated incidents, but they can trigger the same alerting infrastructure when you track a service as a dependency.

How service incidents work

DevHelm adapters poll vendor status pages and detect when a service reports a new incident. Each service incident includes:
  • Title — the vendor’s description of the issue
  • Status — current state (active, resolved, etc.)
  • Impact — severity level reported by the vendor
  • Affected components — which parts of the service are affected
  • Timeline updates — vendor-provided status updates over time
When a service you track as a dependency reports an incident, DevHelm creates a corresponding incident in your organization with source STATUS_DATA. This incident flows through your notification policies based on the alert sensitivity setting.

Viewing service incidents

List incidents for a service

devhelm status-data incidents list github
devhelm status-data incidents list github --status active

Get incident detail

devhelm status-data incidents get github <incident-id>
The detail response includes the full incident plus vendor-provided timeline updates.

Cross-service incidents

View active incidents across all services:
curl https://api.devhelm.io/api/v1/services/incidents?status=active
This is useful for a single-pane view of all vendor outages affecting services in the catalog.

Service incident fields

FieldTypeDescription
idUUIDUnique incident identifier
serviceIdUUIDService that reported the incident
serviceSlugstringService slug (e.g., github)
serviceNamestringService display name
titlestringVendor-provided incident summary
statusstringCurrent state (e.g., active, resolved)
impactstringVendor-reported severity
startedAtdatetimeWhen the incident began
resolvedAtdatetimeWhen the incident was resolved (null if active)
shortlinkstringLink to the vendor’s incident page
detectedAtdatetimeWhen DevHelm first detected the incident

Incident updates

Service incidents include a timeline of vendor-provided updates. Each update represents a status change or progress note from the service provider:
{
  "updates": [
    {
      "status": "investigating",
      "body": "We are investigating reports of degraded performance for API Requests.",
      "displayAt": "2026-04-13T14:30:00Z"
    },
    {
      "status": "identified",
      "body": "The root cause has been identified and a fix is being implemented.",
      "displayAt": "2026-04-13T14:45:00Z"
    },
    {
      "status": "resolved",
      "body": "This incident has been resolved.",
      "displayAt": "2026-04-13T15:10:00Z"
    }
  ]
}

Update fields

FieldTypeDescription
statusstringVendor-reported status for this update
bodystringUpdate message from the vendor
displayAtdatetimeWhen the update was posted

Service incidents vs DevHelm incidents

AspectService incidentDevHelm incident
SourceVendor status pageMonitor checks, manual, or dependency alerts
Created byAutomatic adapter pollingTrigger rules, users, or dependency pipeline
Status modelVendor-defined (investigating, identified, resolved, etc.)DevHelm lifecycle (WATCHING → TRIGGERED → CONFIRMED → RESOLVED)
UpdatesVendor-providedSystem-generated or user-posted
ResolutionWhen vendor marks resolvedRecovery policy, manual, or upstream resolution
When a service incident triggers a DevHelm incident (via a dependency), the two are linked. The DevHelm incident’s serviceIncidentId and serviceId fields reference the source service incident.

Scheduled maintenances

Services also report scheduled maintenance windows:
curl https://api.devhelm.io/api/v1/services/github/maintenances
Maintenances are separate from incidents — they represent planned downtime that the vendor has announced in advance.

Next steps

Dependencies

Add services to get alerted when they have incidents.

Services

Browse the catalog and check current service health.

Your incidents

Understand how dependency incidents appear in your incident list.

Uptime data

Query historical availability for tracked services.