Skip to main content
Status Data lets you track the health of services you depend on — cloud providers, payment processors, CDNs, and SaaS tools — all from your DevHelm organization. When a dependency has an outage, DevHelm detects it and routes alerts through the same notification policies you use for your own monitors.

​
What makes Status Data different

Most status page aggregators simply scrape and display what vendors report. DevHelm goes further:
  • Unified alerting — Third-party incidents flow through your existing notification policies and escalation chains, alongside your own monitor alerts
  • Historical uptime data — Query uptime percentages over configurable periods with hourly, daily, or monthly granularity
  • Component-level tracking — Monitor individual components of a service (API, dashboard, CDN), not just the top-level status
  • Developer context — Each service includes context about what developers care about (API endpoints, SDKs, regions)
  • Plan-based data depth — Historical data access scales with your plan, from 90 days on Free to unlimited on Business+

​
Key concepts

​
Service catalog

DevHelm maintains a catalog of hundreds of services, each tracked via adapters that poll vendor status pages. Services are identified by a human-readable slug (e.g., github, stripe, aws) or UUID. Each service includes:
  • Overall status — current health state
  • Components — individual functional parts (API, dashboard, CDN, regions)
  • Active incidents — currently reported problems
  • Uptime metrics — availability percentages over time
  • Scheduled maintenances — planned downtime windows

​
Dependencies

When you add a service as a dependency, you’re telling DevHelm to notify you when that service has problems. Dependencies connect the Status Data system to your notification policies — incidents from tracked services are routed through the same alerting infrastructure as your own monitor failures.

​
Service incidents

Service incidents represent problems reported by external vendors. They’re distinct from your own monitor-generated incidents but can trigger alerts through the same channels.

​
How it works

Vendor status page updates
        ↓
DevHelm adapter polls and detects change
        ↓
Service status / incident updated in catalog
        ↓
If you track this service as a dependency
        ↓
DevHelm incident created (source: STATUS_DATA)
        ↓
Notification policies evaluated → alerts sent

​
Quick example

Browse the catalog and add a dependency: 
devhelm status-data services list
devhelm status-data services get github
devhelm status-data dependencies add github
Service catalog browsing (list, detail, components, incidents) is public and does not require authentication. Uptime data, dependencies, and comparison endpoints require an API key.

​
Next steps

Services

Browse the catalog, view components and current status.

Dependencies

Add services and configure alert sensitivity.

Service incidents

Track third-party outages and their timelines.

Uptime data

Query historical availability with configurable periods.