Skip to main content

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 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 status-data dependencies add github
devhelm status-data dependencies add stripe
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 status-data dependencies update <dependency-id> \
  --alert-sensitivity 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. When componentId is set on a dependency, only incidents affecting that component trigger alerts.

Listing dependencies

devhelm status-data dependencies list

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 status-data dependencies remove <dependency-id>
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.