Status Data Incidents

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 services incidents github
devhelm services incidents github --status active

curl "https://api.devhelm.io/api/v1/services/github/incidents?status=active"

curl "https://api.devhelm.io/api/v1/services/github/incidents?status=resolved"

Get incident detail

devhelm services incidents github <incident-id>

curl https://api.devhelm.io/api/v1/services/github/incidents/<incident-id>

The detail response includes the full incident plus vendor-provided timeline updates.

Cross-service incidents

View active incidents across all services:

devhelm services incidents --status active

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

Field	Type	Description
`id`	UUID	Unique incident identifier
`serviceId`	UUID	Service that reported the incident
`serviceSlug`	string	Service slug (e.g., `github`)
`serviceName`	string	Service display name
`title`	string	Vendor-provided incident summary
`status`	string	Current state (e.g., `active`, `resolved`)
`impact`	string	Vendor-reported severity
`startedAt`	datetime	When the incident began
`resolvedAt`	datetime	When the incident was resolved (null if active)
`shortlink`	string	Link to the vendor’s incident page
`detectedAt`	datetime	When 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

Field	Type	Description
`status`	string	Vendor-reported status for this update
`body`	string	Update message from the vendor
`displayAt`	datetime	When the update was posted

Service incidents vs DevHelm incidents

Aspect	Service incident	DevHelm incident
Source	Vendor status page	Monitor checks, manual, or dependency alerts
Created by	Automatic adapter polling	Trigger rules, users, or dependency pipeline
Status model	Vendor-defined (investigating, identified, resolved, etc.)	DevHelm lifecycle (WATCHING → TRIGGERED → CONFIRMED → RESOLVED)
Updates	Vendor-provided	System-generated or user-posted
Resolution	When vendor marks resolved	Recovery 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:

devhelm services maintenances github

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.

Getting Started

Monitoring as Code

Monitoring

Incidents

Alerting

Status Data

Platform

Common Patterns

Status Data Incidents

How service incidents work

Viewing service incidents

List incidents for a service

Get incident detail

Cross-service incidents

Service incident fields

Incident updates

Update fields

Service incidents vs DevHelm incidents

Scheduled maintenances

Next steps

Dependencies

Services

Your incidents

Uptime data

​How service incidents work

​Viewing service incidents

​List incidents for a service

​Get incident detail

​Cross-service incidents

​Service incident fields

​Incident updates

​Update fields

​Service incidents vs DevHelm incidents

​Scheduled maintenances

​Next steps

Dependencies

Services

Your incidents

Uptime data

How service incidents work

Viewing service incidents

List incidents for a service

Get incident detail

Cross-service incidents

Service incident fields

Incident updates

Update fields

Service incidents vs DevHelm incidents

Scheduled maintenances

Next steps