Statuspage vs self-hosted status pages
The obvious answer to a $399 a month bill is to run something free. It works, but not for the reason people expect: Statuspage does no monitoring at all, so what you are replacing is the subscriber list, and two of the three popular open-source options have no subscriber list to offer.
Self-host if your status page is for your own team and your own dashboards, or if you pick OpenStatus, the one AGPL-3.0 option that does support email, RSS and JSON subscriptions. Stay on a hosted page if you owe customers an email when things break and you were counting on Uptime Kuma or Upptime to send it, because neither can.
Side by side
Statuspage vs the three self-hosted options
| Statuspage | OpenStatus | Uptime Kuma | Upptime | |
|---|---|---|---|---|
| Licence | Proprietary, cloud only | AGPL-3.0 | MIT | MIT code, ODbL data |
| Visitor can subscribe | ✓ email, SMS, Slack, webhook | ✓ email, RSS/Atom, JSON | ✗ team notifications only | ✗ no email list |
| Built-in monitoring | ✗ none by design | ✓ down to 30-second checks on cloud Pro | ✓ 20-second intervals | ✓ every 5 minutes via GitHub Actions |
| Cost to run | $29 to $1,499/mo by tier | Your host, or $0 to $500/mo cloud | Your host | $0 on GitHub Actions and Pages |
| Managed cloud option | ✓ the only option | ✓ Hobby free to Scale $500/mo | ✗ self-host only | ✗ GitHub only |
| Community size | Atlassian product | about 8.9k stars | ✓ about 89.8k stars | about 17.1k stars |
| Where incidents live | The page, plus Atlassian tools | The page, with status reports | The page, manual | ✗ GitHub Issues, one per outage |
| Audience-specific visibility | ✓ dedicated product from $300/mo | IP restriction on Scale tier | ✗ public or nothing | ✗ public repo, public page |
| Failure-domain risk | ✓ nothing of yours to fall over | ✗ yours to isolate if self-hosted | ✗ one box you must keep alive | ✓ runs on GitHub, not on you |
| Best for | Customer comms with procurement already cleared | Teams that need subscribers and want the source | Internal and homelab monitoring | Open-source projects already on GitHub |
Sources: Atlassian docs · OpenStatus docs and pricing · Uptime Kuma and issue #3022 · Upptime. Star counts read August 2026.
What self-hosting actually replaces
Not the monitoring, because Statuspage never did any
Atlassian's own documentation says Statuspage does no direct monitoring of your websites or servers; you either connect a monitoring tool or drive the page through its API. So the free tools are not replacing a checker you were paying Atlassian for. They are replacing the notification layer, and adding a checker you probably already have.
The subscriber list is the part that is hard to replace
Uptime Kuma is the most popular self-hosted uptime tool by a wide margin and it will alert your team through more than ninety channels. What it will not do is let a visitor on your public page enter an email address. The request was closed as not planned in issue #3022, and it keeps coming back as new issues without landing. Upptime has the same gap: it posts to Slack and opens a GitHub Issue per outage, but there is no customer mailing list. If your support inbox fills up during an incident because nobody was told, neither of these fixes that.
OpenStatus is the exception, and it is why it is on the shortlist despite being much smaller. Its docs describe email, RSS and Atom, and JSON subscriptions, with subscribers emailed whenever a status report is created or updated. Self-hostable under AGPL-3.0, with a cloud tier if you would rather not run it, and it is the only option here that covers both halves of the job.
Do not host the page in the same failure domain as the product
A status page earns its keep in the hour everything else is broken. Put it on the same cluster, region, database or DNS account as the thing it reports on and you have built a page that goes dark exactly when it is needed. If you self-host, isolate it deliberately: a different provider, a static host or an object store, DNS managed somewhere else. Upptime's whole design is a response to this problem, running the checks on GitHub Actions and publishing to GitHub Pages, which is a fair trade for its 5-minute interval.
When paying is the cheaper answer
Someone has to keep the self-hosted page patched, its TLS renewed and its notification credentials current, and that person is on your payroll. At Statuspage Hobby prices, $29 a month, the hosted page costs less than the hour a quarter you will spend on upkeep. The calculation only flips decisively at the top of Statuspage's range, where $399 or $1,499 a month buys a lot of maintenance time.
Procurement is the other honest argument. A tool that is already approved and already invoiced is often faster to keep than a free one that needs a new vendor review, a security questionnaire and a home to run in. And if you need audience-specific pages, where each customer sees only its own components, none of the free options model that properly; the closest is OpenStatus IP restriction on its top cloud tier.
Moving from Statuspage to a self-hosted page
The path most teams take:
1. Answer the subscriber question first. If you owe customers proactive notification, your shortlist is OpenStatus, full stop. If the page is for internal visibility, Uptime Kuma is the stronger tool and the bigger community.
2. Pick the host before the software. Decide where the page runs such that it survives your worst outage, and check that its DNS is not in the same account as production.
3. Export before you cancel. Pull components, incident history and the uptime numbers you quote in contracts out through the Statuspage API. The page and its history vanish with the subscription.
4. Overlap, then re-collect subscribers. Keep the Atlassian page live for one billing cycle, link the new one from it and from your product, and let people opt in again. Confirmed email and SMS lists should not be bulk-loaded into a new sender.
Common questions
FAQ: self-hosted status pages
Can customers subscribe to an Uptime Kuma status page?
No. Uptime Kuma sends notifications to your team through more than 90 integrations, but a visitor looking at your public status page has no way to enter an email address and be told about the next incident. The feature request was closed as not planned in issue #3022, and it has been reopened as new requests since, most recently in 2026, without landing. If your reason for having a status page is that customers should not have to keep refreshing it, this is the gap that matters, and no amount of self-hosting closes it.
Which self-hosted status page supports email subscribers?
OpenStatus, which is AGPL-3.0 and documents self-hosting through Docker and Coolify. Its docs state that visitors can subscribe by email, RSS or Atom, or JSON, and that subscribers receive an email whenever a status report is created or updated. That makes it the only pick on our shortlist that you can run yourself and that still replaces what Statuspage actually charges for. The project is smaller than Uptime Kuma, at roughly 8.9k stars against 89.8k, so weigh the feature against the size of the community behind it.
Is it a bad idea to host your status page on your own infrastructure?
It is the classic mistake, and it is easy to make by accident. A status page exists to work during your worst hour, so if it shares a cluster, a region, a database or a DNS zone with the product it reports on, the outage that most needs communicating is the one that takes the page down too. If you self-host, put the page somewhere with no shared failure domain: a different provider, a static host or an object store, on a domain whose DNS is not managed by the same account. Upptime sidesteps this by running on GitHub Actions and publishing to GitHub Pages, which is why it stays useful despite its 5-minute checks.