sademban's blog

9 October 2025

Service health checks: official status pages and curl checks

by sademban

Service health checks: official status pages and curl checks

When something breaks in a stack, the first question is usually “what changed?” Sometimes the answer is local: a deploy, a DNS change, a bad secret, or a failed migration. Sometimes the answer is upstream: a partial outage in GitHub, AWS, Cloudflare, npm, or another service the app depends on.

This is a short reference for that second case: official status pages, programmatic status endpoints where they exist, and small curl checks that are useful during triage.

Tip: many services host their status pages on Statuspage.io and expose a small JSON API at /api/v2/status.json or /api/v2/summary.json. If the status page looks healthy but your app is affected, check the provider’s API and region-specific dashboards.

How to use this guide

  • Use the status page for human-facing updates and historical incidents.
  • Use the API or /api endpoints for automation (monitoring, alerts, incident correlation).
  • If a provider uses a managed CMP or feature flag, check their control plane (e.g., AWS Service Health Dashboard, Azure Service Health) for region-specific notices.
  • Example curl patterns below assume jq is available for pretty JSON parsing. If you don’t have jq, add it or just inspect plain output.

Repositories & Source Control

CI / CD / Build

Cloud providers & Platform

Hosting, CDN & Edge

Registries & Package Managers

Databases & Managed DBs

Observability & Alerts

Payments and APIs

CDNs, Edge and DDoS protection

  • CloudFront (AWS)
    • See AWS Service Health Dashboard
  • Cloudflare (see above)

Programmatic healthchecks — patterns and examples

Most Statuspage.io-based services expose /api/v2/status.json or /api/v2/summary.json. A small shell snippet:

# generic statuspage check (works for many providers using Statuspage.io)
URL="https://www.githubstatus.com/api/v2/status.json"
curl -s "$URL" | jq .

# check that the status is 'operational' (Statuspage uses readable descriptions)
curl -s "$URL" | jq -r '.status.description'

For endpoints that return summary objects (with component status lists):

URL="https://www.cloudflarestatus.com/api/v2/summary.json"
curl -s "$URL" | jq -r '.status.description'
curl -s "$URL" | jq -r '.components[] | "\(.name): \(.status)"'

For an HTTP code-only quick check, use the status page URL directly. This is not enough for incident detail, but it is useful for simple monitoring:

curl -I -s -o /dev/null -w "%{http_code} %{url_effective}\n" https://www.githubstatus.com/

Automating checks in CI or uptime monitors

  • Use a monitoring job that polls the Statuspage API every 1–5 minutes (respect provider rate limits).
  • Correlate upstream incidents with your app telemetry (errors, latency, rollout times) to avoid chasing false positives.
  • Configure alerts with a short cool-down window and add escalation rules — outages in global CDNs often trigger bursts of alerts.

When the status says “operational” but you’re still affected

  1. Check region-specific dashboards (cloud providers often have region incidents).
  2. Inspect recent deploys, feature flags, or DNS changes in your system.
  3. Use traceroute/mtr to check network path to the provider.
  4. Test from multiple locations (local dev, CI runner, an external host) to isolate whether it’s a client-specific issue.

Final note

Treat provider status pages as one signal, not the whole incident review. If the provider says everything is healthy but your users are still affected, compare the provider status with your own deploy timeline, metrics, logs, DNS state, and checks from more than one network.