Dependencies

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:

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

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

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

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

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

Getting Started

Monitoring as Code

Monitoring

Incidents

Alerting

Status Data

Platform

Common Patterns

Adding a dependency

Alert sensitivity

Updating sensitivity

Component-level dependencies

Listing dependencies

Dependency fields

Removing a dependency

Plan limits

How dependency alerts flow

Next steps

Services

Service incidents

Notification policies

Tracking dependencies guide

​Adding a dependency

​Alert sensitivity

​Updating sensitivity

​Component-level dependencies

​Listing dependencies

​Dependency fields

​Removing a dependency

​Plan limits

​How dependency alerts flow

​Next steps

Services

Service incidents

Notification policies

Tracking dependencies guide

Adding a dependency

Alert sensitivity

Updating sensitivity

Component-level dependencies

Listing dependencies

Dependency fields

Removing a dependency

Plan limits

How dependency alerts flow

Next steps