> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Status Data Incidents
> Track and view third-party service incidents in DevHelm Status Data
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](/incidents/overview), but they can trigger the same alerting infrastructure when you track a service as a [dependency](/status-data/dependencies).
## 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](/alerting/notification-policies) based on the [alert sensitivity](/status-data/dependencies#alert-sensitivity) setting.
## Viewing service incidents
### List incidents for a service
```bash CLI theme={null}
devhelm services incidents github
devhelm services incidents github --status active
```
```bash API theme={null}
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
```bash CLI theme={null}
devhelm services incidents github
```
```bash API theme={null}
curl https://api.devhelm.io/api/v1/services/github/incidents/
```
The detail response includes the full incident plus vendor-provided timeline updates.
### Cross-service incidents
View active incidents across all services:
```bash CLI theme={null}
devhelm services incidents --status active
```
```bash API theme={null}
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:
```json theme={null}
{
"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:
```bash CLI theme={null}
devhelm services maintenances github
```
```bash API theme={null}
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
Add services to get alerted when they have incidents.
Browse the catalog and check current service health.
Understand how dependency incidents appear in your incident list.
Query historical availability for tracked services.