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
STATUS_DATA. This incident flows through your notification policies based on the alert sensitivity setting.
Viewing service incidents
List incidents for a service
Get incident detail
Cross-service incidents
View active incidents across all services: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: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 |
serviceIncidentId and serviceId fields reference the source service incident.
Scheduled maintenances
Services also report scheduled maintenance windows: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.