Docker Status APIdockerstatus.com ↗
Monitor Docker's real-time service health, incident history, and RSS feed via the dockerstatus.com API. 5 endpoints covering all services and past incidents.
What is the Docker Status API?
The Docker Status API exposes 5 endpoints that surface Docker's current platform health, per-service operational status, and full incident history as reported on dockerstatus.com. The get_all_services_status endpoint returns every Docker service with nested container-level status codes, while get_incident_history provides a timestamped update timeline for each past incident, filterable by component or container ID.
No input parameters required.
curl -X GET 'https://api.parse.bot/scraper/2abe8c54-9d74-40c0-ac54-5b470c179510/get_overall_status' \ -H 'X-API-Key: $PARSE_API_KEY'
Typed, relational, agent-ready
A generated client with real types, enums, and the links between objects — the structure a flat JSON response can't carry. Autocompletes in your editor and reads cleanly to coding agents.
- Fully typed · autocompletes
- Objects link to objects
- Typed errors & pagination
Typed Python client. Set up the SDK in your uv project, then pull this API’s typed client:
uv add parse-sdk uv run parse init uv run parse add --marketplace dockerstatus-com-api
uv run parse add --marketplace pulls a pinned snapshot of this canonical API — it won’t change underneath you. To customize it, subscribe and swap to your own copy.
"""Walkthrough: Docker Status API — monitor services, investigate incidents, check RSS feed."""
from parse_apis.docker_status_api import DockerStatus, ServiceName, ServiceNotFound
client = DockerStatus()
# Check overall platform health — single lightweight call.
overall = client.statuses.get()
print(f"Platform: {overall.status} (code {overall.status_code}, updated {overall.updated_at})")
# Look up a specific service by enum name.
hub = client.services.get(service_name=ServiceName.DOCKER_HUB_REGISTRY)
print(f"Docker Hub Registry: {hub.status} (updated {hub.updated})")
for container in hub.containers:
print(f" Container: {container.name} — {container.status}")
# Drill into one service's incidents.
service = client.services.list(limit=1).first()
if service:
for incident in service.incidents(limit=3):
print(f" Incident: {incident.title} — {incident.status} ({incident.date})")
for upd in incident.updates:
print(f" [{upd.status}] {upd.message}")
# Typed error handling: look up a non-existent service.
try:
bad = client.services.get(service_id="nonexistent_id_000")
print(bad.name)
except ServiceNotFound as exc:
print(f"Service not found: {exc}")
# RSS feed — recent status updates.
for item in client.feeditems.list(limit=3):
print(f" [{item.pub_date}] {item.title} — {item.link}")
print("Exercised: statuses.get / services.get / services.list / service.incidents / feeditems.list")
Returns the overall system status banner (e.g., 'Operational') and the last-updated timestamp from Docker's status page. A single lightweight call that summarizes the entire platform health.
No input parameters required.
{
"type": "object",
"fields": {
"status": "string indicating overall system state (e.g. 'Operational')",
"updated_at": "string ISO 8601 timestamp of last update",
"status_code": "integer status code (100 = operational)"
},
"sample": {
"data": {
"status": "Operational",
"updated_at": "2026-06-11T05:30:05.234Z",
"status_code": 100
},
"status": "success"
}
}About the Docker Status API
Service Health Data
The get_overall_status endpoint returns a single-string system state (e.g., 'Operational') alongside an ISO 8601 updated_at timestamp and a numeric status_code where 100 signals fully operational. For per-service detail, get_all_services_status returns every service with its id, name, status, updated timestamp, and a containers array — each container carrying its own id, name, status, status_code, and updated fields. This lets you distinguish, for example, whether a regional container within Docker Hub Registry is degraded while the top-level service shows operational.
Querying a Single Service
When you only care about one service, get_service_status accepts either service_id or service_name (case-insensitive). At least one parameter is required. The response shape is identical to a single entry from get_all_services_status, including the nested containers array, so you can slot it into the same parsing logic.
Incident History and RSS Feed
get_incident_history returns past incidents with a full updates array — each update includes a timestamp, status, and message — plus locations and components arrays that name the affected parts of Docker's infrastructure. You can scope results by passing a component_id or container_id filter. For teams that prefer feed-based monitoring, get_rss_feed returns RFC 2822-dated RSS items with HTML-formatted description fields and direct link URLs to each incident's detail page on dockerstatus.com.
The Docker Status API is a managed, monitored endpoint for dockerstatus.com — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when dockerstatus.com changes and a check fails, the API is automatically queued for repair and re-verified. It is built to keep working as the site underneath it changes.
This isn't an official dockerstatus.com API — it's an independent, maintained REST wrapper over public data. Where the source has no official API (or only a limited one), Parse gives you a stable contract over a source that never promised one, and keeps it current. Need a new endpoint or field? You can revise it yourself in plain English and the agent rebuilds it against the live site in minutes — contributing the change back to the shared API is free.
Will this API break when the source site changes?+
Is this an official API from the source site?+
Can I fix or extend this API myself if I need a new endpoint or field?+
What happens if I call an endpoint that has an issue?+
- Alert on-call engineers when
get_overall_statusreturns a non-operationalstatus_code - Build a dashboard that polls
get_all_services_statusto display container-level health per Docker region - Integrate
get_service_statusinto a CI pipeline to gate deployments when Docker Hub Registry is degraded - Populate a post-mortem database by ingesting
get_incident_historywith its timestampedupdatesarray - Filter
get_incident_historybycomponent_idto audit how often a specific Docker service has experienced incidents - Ingest
get_rss_feedinto a Slack bot or ticketing system for incident notifications as they are published
| Tier | Price | Credits/month | Rate limit |
|---|---|---|---|
| Free | $0/mo | 100 | 5 req/min |
| Hobby | $30/mo | 1,000 | 20 req/min |
| Developer | $100/mo | 5,000 | 100 req/min |
One credit = one API call regardless of which marketplace API you call. Exceeding the rate limit returns a 429 response. Authenticate with the X-API-Key header.
Does Docker have an official developer API for status data?+
What does the `containers` field in service responses actually represent?+
containers are sub-components or regional breakdowns within a service — not Docker containers in the runtime sense. Each entry has its own id, name, status, status_code, and updated timestamp, so you can detect partial degradation (e.g., one region affected) even when the parent service status shows operational.Can I filter incident history by date range?+
get_incident_history supports filtering by component_id or container_id but does not accept date range parameters. The response includes a human-readable date field and ISO timestamps in each updates entry, so client-side filtering by date is straightforward. You can fork this API on Parse and revise it to add a date range filter endpoint.Does the API expose historical uptime percentages or SLA metrics?+
How fresh is the data from `get_overall_status`?+
updated_at field in the response carries the ISO 8601 timestamp of the last update as reported by dockerstatus.com. The freshness of data reflects when Docker last updated their status page, not a fixed polling interval. For time-sensitive monitoring, compare updated_at against your own request time to detect staleness.