Atlassian Statuspage alternative for teams who need the checks too
Statuspage does no monitoring of its own, so you are paying for the page plus whatever tool feeds it, while Logdash runs the HTTP checks and publishes the page from the same monitors.
Statuspage is the default for good reasons. It is the page customers recognise, the component model matches how large systems are actually organised, and the subscriber list scales past numbers most tools ever see.
It also checks nothing. Atlassian says so in their own docs: Statuspage does not do any direct monitoring of your websites or servers. Components change colour when a person clicks them, when an integration says so, or when something calls the API. The real stack is a checker, plus Statuspage, plus the glue between them, and the glue fails quietly. The token expires, the automation stops firing, and the page says everything is fine right through an outage.
Logdash removes the middle piece. The HTTP monitor that decides your API is down is the same object the public page renders, and the Telegram or webhook alert goes out at the same moment. There is no integration to keep authorised.
What you give up is real. Statuspage has email and SMS subscribers, audience-specific pages, component groups, scheduled maintenance and links into Jira, Opsgenie and PagerDuty. Logdash has a hosted page on a custom domain, and the same data as JSON for a page you build yourself. If your status page has thousands of subscribers and an SLA attached, stay where you are.
The check behind the component
import express from 'express';
const app = express();
app.get('/health', async (_req, res) => {
try {
await db.query('select 1');
res.status(200).json({ status: 'ok' });
} catch {
res.status(503).json({ status: 'down', reason: 'database' });
}
});
app.listen(3000);- Point a monitor at the endpoint One URL, checked every 5 minutes on the free plan and every 15 seconds on Pro. Status code and response time are recorded from the first check, so you have history before you have a page.
- Publish the page Add the monitor to a public status page and map your status subdomain to it. Nothing to authorise, no API token to rotate every year.
- Add the alert Attach a Telegram channel to the monitor, then take the service down on purpose. The alert reaches your chat while the page is still repainting.
Statuspage API alternative
Statuspage already has a public API. Every public page serves JSON at /api/v2/summary.json with no key, and the REST API manages components and incidents with one. So the API alone is no reason to move. Logdash serves the same kind of public JSON at /v1/status_pages/:id: overall status, uptime per monitor for 1 hour up to 90 days, 90 daily buckets and the last 100 checks. The difference is what ships on top of it. A typed client on npm, a status page component you copy into a React or Svelte app with one command, and a Next.js starter that deploys to Vercel in one click. For a page inside your own site, Statuspage hands you the data and leaves the rendering to you.
# Statuspage: public JSON for any page, no key
curl https://metastatuspage.com/api/v2/summary.json
# Logdash: the same idea, with the checks behind it
curl https://api.logdash.io/v1/status_pages/your-status-page-id
# What Statuspage does not ship: the page, as code in your app
npx shadcn add https://logdash.io/r/react/status-page.jsonLogdash vs Statuspage
| Feature | Logdash | Statuspage |
|---|---|---|
| Runs the checks | Built in, the monitor drives the page | None, you bring your own checker |
| Moving parts between check and page | None | An integration or an API call you maintain |
| Open source | AGPL-3.0, source on GitHub | Closed source |
| Custom domain | Point your own domain at it | Point your own domain at it |
| Notifying customers | None, alerts go to your team | Email, SMS and Slack subscribers |
| Modelling a large system | A flat list of monitors | Component groups and audience-specific pages |
| Incident workflow | None, the page shows check results only | Templates, maintenance windows, Jira and Opsgenie |
| Status page in your own code | Public JSON, typed client, component, starter | Public JSON, the page is yours to write |
When Statuspage is the better pick
- Your customers subscribe by email or SMS and expect to be told. Logdash has no subscriber notifications at all.
- You have components, groups and separate pages for separate audiences. That model does not exist here.
- Your incident process runs through Jira, Opsgenie or PagerDuty and the page has to move with it.
- Procurement already approved Atlassian. That is a real reason and it outranks most technical ones.
What moving actually looks like
Map each component to one HTTP monitor. A component with no check behind it is common, and worth knowing about. Publish the Logdash page on a subdomain and run both for two weeks. Before you move DNS, tell your subscribers, because that list does not come with you.