Status page API

Every status page you publish in Logdash is also public JSON at api.logdash.io/v1/status_pages/:id, with no API key and CORS open to any origin, so you can render it on your own site in your own design.

Most status page products give you a hosted page and stop there. The page lives on their domain in their fonts, and anything beyond it means scraping HTML. Logdash serves the data its hosted page renders as JSON, one endpoint per page. Anything that can make an HTTP request can read it: your marketing site, a banner inside your app, a CLI, a menu bar widget.

Call the status page API with curl

curl https://api.logdash.io/v1/status_pages/status.logdash.io

That is the Logdash status page itself, so the command works as pasted. Swap in your own status page id, which is the last part of its public logdash.io/d/ URL, or a verified custom domain such as status.example.com. The page has to be published: a draft answers 403 and an unknown id answers 404.

The response shape

{
  "name": "Acme",
  "status": "operational",
  "updatedAt": "2026-10-02T12:00:00.000Z",
  "monitors": [
    {
      "id": "Xq3vN8kP2mLw",
      "name": "API",
      "status": "up",
      "uptime": { "1h": 100, "24h": 100, "7d": 99.98, "30d": 99.95, "90d": 99.97 },
      "history": {
        "daily": [
          {
            "timestamp": "2026-10-02T00:00:00.000Z",
            "successCount": 720,
            "failureCount": 0,
            "averageLatencyMs": 182
          }
        ]
      },
      "pings": [
        { "createdAt": "2026-10-02T11:59:00.000Z", "statusCode": 200, "responseTimeMs": 175 }
      ]
    }
  ]
}

status is the whole page: operational, degraded, outage or unknown.
monitors[].status is up, degraded, down or unknown, computed on the server from the latest 10 checks, so every client shows the same thing.
uptime is a percentage over 1 hour, 24 hours, 7, 30 and 90 days. null means no checks in that window.
history.daily always has 90 UTC days, oldest first, each with success and failure counts and average latency.
pings holds the last 100 checks, each with its status code and response time.

Use the typed client

@logdash/status on npm wraps the same endpoint with types generated from the OpenAPI spec and zero runtime dependencies. fetchStatusPage makes one request and throws a StatusPageError carrying the HTTP status, so a 404 is easy to tell apart from a network failure.

import { fetchStatusPage } from '@logdash/status';

const page = await fetchStatusPage('status.logdash.io');

console.log(page.name, page.status);
for (const monitor of page.monitors) {
  console.log(monitor.name, monitor.status, monitor.uptime['90d']?.toFixed(2));
}

For a live page, the React hook and the Svelte binding poll every 60 seconds, pause in hidden tabs and keep the last good data when a request fails. That last part is what most people get wrong when they write a headless status page from scratch: the first network blip blanks the page at the exact moment visitors are reading it.

Caching and limits

The server composes a page at most once a minute and answers with Cache-Control: public, max-age=60, so polling faster brings nothing new, and what a visitor sees can be up to about three minutes old. Show updatedAt so they know. The API is read only. Incidents, maintenance windows and subscriber emails are not in it, because the hosted page does not have them either.

Statuspage API vs the Logdash status page API

Logdash vs Atlassian Statuspage

Feature	Logdash	Statuspage
Public read endpoint	One JSON URL per page, no key	summary.json on every page, no key
Where status comes from	HTTP checks every 5 minutes to 15 seconds	Set by hand or by an integration
Write API	None, the API only reads	Manage API, with an API key
Incidents and maintenance	Not in the data	Incidents, scheduled maintenance, components
Building your own page	MIT typed client, React and Svelte components, Next.js starter	A JavaScript embed library

When Statuspage is the better pick

You post incidents and maintenance windows and want them in the JSON. Logdash has no incident model at all.
You need to write status from code, such as opening an incident from a deploy script. The Logdash API only reads.
Your status covers things an HTTP check cannot see, and a person sets it by hand.

From zero to a page that alerts you

Publish a status page Add your monitors to a status page in Logdash, publish it and copy the id from the Build your own section.
Fetch it Curl the endpoint or install @logdash/status. The JSON is the same on every plan. Only the check interval changes: 5 minutes free, 1 minute on Builder, 15 seconds on Pro.
Break something on purpose Stop the service behind one monitor. The next check fails, its status in the JSON turns down, and a Telegram alert lands saying the monitor is down, with the status code and the error.

The full field reference, status rules and error codes live in the docs at /docs/status-pages.

Does the status page API need an API key?

No. Reading a published status page needs no key and no account, and CORS allows any origin, so a browser can call it straight from your site. There is nothing secret to leak. Creating and editing status pages happens in the Logdash dashboard, and personal API keys do not reach those endpoints today.

Where is the status page API documentation?

At /docs/status-pages on logdash.io. It covers every response field, the status rules, caching, CORS and errors, plus the client library, the shadcn component and the Next.js starter. The version is part of the path, and a change that would break an existing client gets a new version.

Is there an Uptime Kuma status page API?

Yes. A published Kuma status page answers at /api/status-page/:slug with its config and at /api/status-page/heartbeat/:slug with recent heartbeats and a 24-hour uptime per monitor. Kuma documents it on its internal API wiki page, which says that API is meant for the app itself and not officially supported for third-party use.

Is there a Cloudflare status page API?

Yes. cloudflarestatus.com runs on Atlassian Statuspage, so the standard v2 endpoints work with no key: /api/v2/status.json for the overall indicator and /api/v2/summary.json for components and open incidents. It tells you about Cloudflare, not about your app behind it.

Is there an AWS status page API or an Azure status page API?

Not a public, documented one. The AWS Health API covers events for your own account and needs a Business Support+, Enterprise or Unified Operations plan. Azure publishes an RSS feed of broad incidents, and its Resource Health REST API covers your subscription behind Azure sign-in. A check on your own endpoint catches the outages that actually touch you.