> ## 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

<CodeGroup>
  ```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"
  ```
</CodeGroup>

### Get incident detail

<CodeGroup>
  ```bash CLI theme={null}
  devhelm services incidents github <incident-id>
  ```

  ```bash API theme={null}
  curl https://api.devhelm.io/api/v1/services/github/incidents/<incident-id>
  ```
</CodeGroup>

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

### Cross-service incidents

View active incidents across all services:

<CodeGroup>
  ```bash CLI theme={null}
  devhelm services incidents --status active
  ```

  ```bash API theme={null}
  curl "https://api.devhelm.io/api/v1/services/incidents?status=active"
  ```
</CodeGroup>

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:

<CodeGroup>
  ```bash CLI theme={null}
  devhelm services maintenances github
  ```

  ```bash API theme={null}
  curl https://api.devhelm.io/api/v1/services/github/maintenances
  ```
</CodeGroup>

Maintenances are separate from incidents — they represent planned downtime that the vendor has announced in advance.

## Next steps

<CardGroup cols={2}>
  <Card title="Dependencies" icon="link" href="/status-data/dependencies">
    Add services to get alerted when they have incidents.
  </Card>

  <Card title="Services" icon="server" href="/status-data/services">
    Browse the catalog and check current service health.
  </Card>

  <Card title="Your incidents" icon="circle-exclamation" href="/incidents/overview">
    Understand how dependency incidents appear in your incident list.
  </Card>

  <Card title="Uptime data" icon="chart-line" href="/status-data/uptime">
    Query historical availability for tracked services.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.