Skip to main content
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 — the same infrastructure that handles your own monitor alerts.

​
Adding a dependency

devhelm dependencies track github
devhelm dependencies track stripe

curl -X POST https://api.devhelm.io/api/v1/service-subscriptions/github \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"

# devhelm.yaml — applied with `devhelm deploy`
dependencies:
  - service: github
  - service: stripe
    alertSensitivity: INCIDENTS_ONLY

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.

​
Alert sensitivity

Control which service events trigger incidents — and whether they page anyone — with the alertSensitivity setting:
LevelBehavior
AWARENESSDefault. 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_ONLYPage when the service reports a real incident (any severity)
ALLPage on all status changes, including synthetic degradations
MAJOR_ONLYPage only on major outages (highest impact level)

​
Updating sensitivity

devhelm dependencies update <subscription-id> \
  --alert-sensitivity MAJOR_ONLY

curl -X PATCH https://api.devhelm.io/api/v1/service-subscriptions/<dependency-id>/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. 
# Find component IDs first
devhelm services components github

devhelm dependencies track github --component <component-id>

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": "<component-id>" }'
When componentId is set on a dependency, only incidents affecting that component trigger alerts.

​
Listing dependencies

devhelm dependencies list

curl https://api.devhelm.io/api/v1/service-subscriptions \
  -H "Authorization: Bearer $DEVHELM_API_TOKEN"

​
Dependency fields

FieldTypeDescription
subscriptionIdUUIDUnique dependency identifier
serviceIdUUIDTracked service
slugstringService slug (e.g., github)
namestringService display name
categorystringService category
overallStatusstringCurrent service health
componentIdUUIDSpecific component being tracked (null = whole service)
componentobjectComponent detail (when tracking a specific component)
alertSensitivitystringALL, INCIDENTS_ONLY, MAJOR_ONLY, or AWARENESS (track silently)
subscribedAtdatetimeWhen the dependency was added

​
Removing a dependency

devhelm dependencies delete <subscription-id>

curl -X DELETE https://api.devhelm.io/api/v1/service-subscriptions/<subscription-id> \
  -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

PlanMax dependencies
Free10
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 as monitor alerts. Use service_id_in or component_name_in rules to route service alerts to specific channels.

​
Next steps

Services

Browse the catalog to find services you depend on.

Service incidents

View incidents reported by your tracked services.

Notification policies

Route dependency alerts with match rules.

Tracking dependencies guide

Step-by-step guide for setting up dependency tracking.