--- title: "Status page API: public JSON, no key | Logdash" description: "One public endpoint per status page. Curl it or use the typed @logdash/status client. The real response shape, caching rules, and how it compares to the Statuspage API." url: https://logdash.io/status-page/api --- # 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 ```bash 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 ```json { "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. ```typescript 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 1. **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. 2. **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. 3. **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. ## Keep reading [All status page guides](https://logdash.io/status-page): One page per question, from the status page API to a free page on your own domain. [Open source status page](https://logdash.io/status-page/open-source): Logdash is AGPL-3.0 and its status page client, components and Next.js starter are MIT, but the checks and the data run on hosted Logdash, so if the whole stack must run on your own hardware, Uptime Kuma, Gatus or Upptime are the honest picks. [Free status page self hosted](https://logdash.io/status-page/self-hosted): Run the MIT-licensed Logdash Next.js starter on your own server or in Docker for a free self-hosted status page, while the checks behind it stay on the Logdash free plan, because the monitoring itself does not self-host in one command yet. [Free status page](https://logdash.io/status-page/free): The free Logdash Hobby plan includes one public status page fed by up to 5 HTTP monitors checked every 5 minutes, plus Telegram and webhook alerts, uptime badges and the status page API, with no credit card and no trial clock. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.