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 a third-party 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 is the part that 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. There is no integration to keep authorised, because nothing sits between the check and the page. The Telegram or webhook alert goes out at the same moment.
What you give up is real and worth listing. Statuspage has email and SMS subscribers, audience-specific pages, component groups, scheduled maintenance windows and first-class links into Jira, Opsgenie and PagerDuty. Logdash has a public page showing your monitors on a custom domain. If your status page has thousands of subscribers and an SLA attached to it, 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);There is a second shape for the things that have no URL. Nightly billing runs, queue workers, sync scripts. Give each one a monitor and have the job POST to https://api.logdash.io/ping/<monitorId> when it finishes. That endpoint is public and takes no body and no auth header, so it is one line at the end of the script. Miss the window and the monitor goes down like any other, which is a class of failure a status page with no checker behind it will never notice.
- 1 Point a monitor at the endpoint One URL, one interval. Status code and response time are recorded from the first check, so you have history before you have a page.
- 2 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.
- 3 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.
Logdash 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 | MIT, 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 | Post an update on the page | Templates, maintenance windows, Jira and Opsgenie |
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. If a component turns out to have no check behind it, that is worth knowing on its own, and it is common. Publish the Logdash page on a subdomain and run both for a couple of weeks so you can compare what each one showed during a real incident. Before you move DNS, tell your subscribers, because that list does not come with you and there is no import.
Is there an open source alternative to Statuspage?
Logdash is MIT licensed with the source on GitHub, and it runs the checks as well as the page. Cachet is the other common answer if you need something you can deploy yourself today.
Does Statuspage monitor uptime?
No. Atlassian states that Statuspage does not do any direct monitoring of your websites or servers. Components are updated by a person, by an integration or through the API.
Can I move my Statuspage subscribers?
No. Subscriber lists do not transfer between providers, and Logdash has no subscriber notifications, so give people notice on the old page well before you switch.
What replaces the monitoring tool feeding Statuspage?
The Logdash monitor is the checker. You drop the separate uptime tool and the integration, and the page reads from the same monitors that send your Telegram alerts.