Your Status Page Is for Humans. Your JSON Feed Is for Everything Else.
A status page tells your customers whether your service is up. But most of the people who care about your uptime aren't refreshing a webpage — they're running automated systems that need to know when something breaks.
A JSON feed turns your status page from a manual check into a machine-readable API that your customers' tools can consume directly. It's the difference between "go look at our status page" and "here's a feed your monitoring system can subscribe to."
What Is a Status Page JSON Feed?
A JSON feed is a structured, machine-readable endpoint that publishes your current service status, active incidents, and historical events in JSON format. It's similar to an RSS or Atom feed, but designed for programmatic consumption rather than feed readers.
A typical status page JSON feed includes:
- Current component status — which services are operational, degraded, or down
- Active incidents — what's happening now, with timestamps and severity
- Incident updates — the timeline of each incident as it progresses
- Scheduled maintenance — upcoming planned downtime windows
Unlike an RSS feed that's designed for human-readable summaries, a JSON feed gives consumers structured fields they can parse, filter, and act on without scraping HTML.
Why Customers Want Machine-Readable Status Pages
Automated Alerting Without Polling Your Status Page
Your largest customers are probably already monitoring your status page. Without a JSON feed, they're doing it the hard way — scraping HTML, checking for text changes, or manually watching for updates.
A JSON feed gives them a clean endpoint to poll. Their monitoring tools (Datadog, PagerDuty, Grafana, custom scripts) can subscribe to your feed and trigger alerts the moment you post an incident. No scraping, no guessing, no missed updates.
Dependency Dashboards
Engineering teams that depend on your service want to see your status alongside their own internal systems. A JSON feed lets them pull your component status into their internal dashboards, giving their on-call engineers a single pane of glass that includes third-party dependency health.
This is increasingly common in platform engineering. Teams building internal developer portals (Backstage, Port, Cortex) want to show the status of every dependency, and a JSON feed is the standard way to do it.
Incident Correlation
When something breaks, the first question is always "is it us or is it a dependency?" A JSON feed from your status page lets your customers' incident management tools automatically correlate their alerts with your incidents.
If your customer's error rates spike at the same time your JSON feed shows a degraded API, their tools can immediately flag the correlation. Without a feed, someone has to manually check your status page during every incident.
Compliance and SLA Tracking
Customers who have SLAs with you need to track your uptime over time. A JSON feed with historical incident data lets them calculate your actual availability without manually logging incidents from your status page.
For regulated industries (finance, healthcare, government), the ability to programmatically audit a vendor's uptime history is often a procurement requirement.
JSON Feed vs. RSS Feed vs. Webhooks
RSS/Atom Feeds
RSS feeds are widely supported and work well for human consumption through feed readers. Most status page tools offer RSS. The limitation is that RSS is designed for sequential updates (like a blog), not structured status data. Parsing component-level status from an RSS description field is fragile.
Best for: Users who want email-style notifications through a feed reader.
JSON Feeds
JSON feeds provide structured data with typed fields. A consumer can programmatically check status: "degraded" instead of parsing a sentence. They're the right choice for integrations, dashboards, and automation.
Best for: Engineering teams building integrations, monitoring tools, and dashboards.
Webhooks
Webhooks push updates to your customer's endpoint in real-time. They're the fastest option — no polling delay. The tradeoff is that webhooks require your customer to run a publicly accessible HTTP endpoint, and they need retry logic for failed deliveries.
Best for: Real-time alerting where polling delay isn't acceptable.
The ideal status page offers all three. JSON feeds and webhooks serve different use cases, and RSS covers the long tail of users who just want simple notifications.
What a Good Status Page JSON Feed Looks Like
A well-designed JSON feed endpoint should:
Return current status in a single request. Don't make consumers hit five endpoints to get the full picture. One GET request should return all components, their current status, and any active incidents.
Use consistent, documented status values. Define your status enum (operational, degraded, partial_outage, major_outage, maintenance) and document it. Consumers are writing if statements against these values.
Include timestamps in ISO 8601. Every incident, update, and status change should have a machine-parseable timestamp with timezone information.
Support filtering. Let consumers request specific components or date ranges rather than forcing them to download your entire incident history on every request.
Be stable. Don't change field names or remove fields without versioning. Your customers are building automation on top of this. A breaking change in your feed is an incident for them.
Here's a minimal example of what a clean JSON feed response looks like:
{
"status": {
"overall": "degraded",
"updated_at": "2026-03-20T14:32:00Z"
},
"components": [
{
"name": "API",
"status": "operational",
"updated_at": "2026-03-20T14:00:00Z"
},
{
"name": "Dashboard",
"status": "degraded",
"updated_at": "2026-03-20T14:32:00Z"
}
],
"active_incidents": [
{
"id": "inc-2026-0320",
"title": "Dashboard loading slowly",
"status": "investigating",
"severity": "minor",
"created_at": "2026-03-20T14:30:00Z",
"updates": [
{
"body": "We're investigating reports of slow dashboard load times.",
"created_at": "2026-03-20T14:32:00Z"
}
]
}
]
}
How to Use a Status Page JSON Feed
If you're consuming a vendor's JSON feed, here are the most common patterns:
Poll and Alert
The simplest integration. Poll the feed every 60 seconds and alert your team when the overall status changes from operational.
# Simple polling example
curl -s https://status.example.com/api/v1/status.json | jq '.status.overall'
Wire this into your existing monitoring tool (Datadog custom check, Prometheus Blackbox, or a simple cron job) and you have automated vendor monitoring.
Feed Into Your Dashboard
Pull component-level status into Grafana, Datadog, or your internal dashboard. Map each component to the service your team depends on, and display it alongside your own health checks.
Trigger Incident Workflows
Connect the feed to your incident management tool. When the feed shows an active incident affecting a component you depend on, automatically create an internal incident or add context to an existing one.
Status Page API Integration Is a Feature, Not a Nice-to-Have
Enterprise buyers increasingly expect a machine-readable status page. It shows up in security questionnaires, vendor assessments, and procurement checklists. "Do you provide a programmatic way to check service status?" is a question your sales team will hear.
A JSON feed is also a trust signal. It says "we're confident enough in our transparency to let you automate the monitoring of our uptime." Companies that only offer a human-readable status page are implicitly asking customers to trust their self-reported status without any way to independently track it.
Alert24 Includes a JSON Feed on Every Status Page
Every Alert24 status page comes with a built-in JSON API that exposes current component status, active incidents, incident history, and scheduled maintenance. Your customers can integrate it into their monitoring stack without any configuration on your side.
Combined with webhook support and RSS feeds, Alert24 gives your customers every option for staying informed about your service health — whether they're a developer building an integration or an ops engineer who just wants a Slack notification.