> ## 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.
# Dependencies
> Track third-party services you depend on and get notified when their status changes
Dependencies connect your organization to services in the Status Data catalog. When you add a service as a dependency, DevHelm monitors its status and routes incidents through your existing [notification policies](/alerting/notification-policies) — the same infrastructure that handles your own monitor alerts.
## Adding a dependency
```bash CLI theme={null}
devhelm dependencies track github
devhelm dependencies track stripe
```
```bash API theme={null}
curl -X POST https://api.devhelm.io/api/v1/service-subscriptions/github \
-H "Authorization: Bearer $DEVHELM_API_TOKEN"
```
```yaml Config-as-code theme={null}
# devhelm.yaml — applied with `devhelm deploy`
dependencies:
- service: github
- service: stripe
alertSensitivity: INCIDENTS_ONLY
```
```hcl Terraform theme={null}
resource "devhelm_dependency" "stripe" {
service = "stripe"
alert_sensitivity = "INCIDENTS_ONLY"
}
```
Once added, any incident reported by the service creates a DevHelm incident with source `STATUS_DATA`.
By default, new dependencies are added in **silent tracking mode** (`AWARENESS`): the incident is created and visible on the dashboard, but no Slack / PagerDuty / Telegram / email / webhook alerts fire. Choose silent tracking when you want to monitor a vendor without paging anyone; switch to one of the paging modes (`INCIDENTS_ONLY`, `ALL`, `MAJOR_ONLY` — see below) to route the incident through your [notification policies](/alerting/notification-policies).
## Alert sensitivity
Control which service events trigger incidents — and whether they page anyone — with the `alertSensitivity` setting:
| Level | Behavior |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `AWARENESS` | **Default.** Track real incidents on the dashboard, but **never page**. No Slack / PagerDuty / Telegram / email / webhook alerts fire. Use when you want to watch a dependency without waking anyone. |
| `INCIDENTS_ONLY` | Page when the service reports a real incident (any severity) |
| `ALL` | Page on all status changes, including synthetic degradations |
| `MAJOR_ONLY` | Page only on major outages (highest impact level) |
### Updating sensitivity
```bash CLI theme={null}
devhelm dependencies update \
--alert-sensitivity MAJOR_ONLY
```
```bash API theme={null}
curl -X PATCH https://api.devhelm.io/api/v1/service-subscriptions//alert-sensitivity \
-H "Authorization: Bearer $DEVHELM_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"alertSensitivity": "MAJOR_ONLY"
}'
```
## Component-level dependencies
You can track a specific component of a service rather than the entire service. This is useful when you only depend on part of a vendor's infrastructure — for example, tracking GitHub's "API Requests" component without alerting on "GitHub Pages" issues.
```bash CLI theme={null}
# Find component IDs first
devhelm services components github
devhelm dependencies track github --component
```
```bash API theme={null}
curl -X POST "https://api.devhelm.io/api/v1/service-subscriptions/github" \
-H "Authorization: Bearer $DEVHELM_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "componentId": "" }'
```
When `componentId` is set on a dependency, only incidents affecting that component trigger alerts.
## Listing dependencies
```bash CLI theme={null}
devhelm dependencies list
```
```bash API theme={null}
curl https://api.devhelm.io/api/v1/service-subscriptions \
-H "Authorization: Bearer $DEVHELM_API_TOKEN"
```
## Dependency fields
| Field | Type | Description |
| ------------------ | -------- | ---------------------------------------------------------------------- |
| `subscriptionId` | UUID | Unique dependency identifier |
| `serviceId` | UUID | Tracked service |
| `slug` | string | Service slug (e.g., `github`) |
| `name` | string | Service display name |
| `category` | string | Service category |
| `overallStatus` | string | Current service health |
| `componentId` | UUID | Specific component being tracked (null = whole service) |
| `component` | object | Component detail (when tracking a specific component) |
| `alertSensitivity` | string | `ALL`, `INCIDENTS_ONLY`, `MAJOR_ONLY`, or `AWARENESS` (track silently) |
| `subscribedAt` | datetime | When the dependency was added |
## Removing a dependency
```bash CLI theme={null}
devhelm dependencies delete
```
```bash API theme={null}
curl -X DELETE https://api.devhelm.io/api/v1/service-subscriptions/ \
-H "Authorization: Bearer $DEVHELM_API_TOKEN"
```
Removing a dependency stops future alerts for that service. Existing incidents from the service are not affected.
## Plan limits
| Plan | Max dependencies |
| -------- | ---------------- |
| Free | 10 |
| Starter+ | Unlimited |
## How dependency alerts flow
```
Service incident detected by adapter
↓
DevHelm creates incident (source: STATUS_DATA)
↓
Alert sensitivity filter applied
↓
If passes → notification policies evaluated
↓
Matching policies → escalation chains execute
↓
Channels notified (Slack, PagerDuty, etc.)
```
Dependency alerts support the same [notification policy match rules](/alerting/notification-policies#match-rules) as monitor alerts. Use `service_id_in` or `component_name_in` rules to route service alerts to specific channels.
## Next steps
Browse the catalog to find services you depend on.
View incidents reported by your tracked services.
Route dependency alerts with match rules.
Step-by-step guide for setting up dependency tracking.