When Statuspage or Uptime Kuma fits your status communication
A renewal notice, a jump in subscriber pricing or a data residency question is usually what sends a team to look at alternatives to Atlassian Statuspage. The first decision is not which tool has more features but who must receive notifications and where the status data must live. Statuspage fits teams that want a managed, hosted status page with subscriber notifications and a component model, with no servers for them to run. Its value is that Atlassian operates the publishing side, so the team spends its effort on writing incidents rather than keeping a status site online. That advantage matters most when the audience is large, when subscribers need self-service email or SMS updates, and when nobody on the team wants to own uptime of the status page itself.
Uptime Kuma fits a different situation. It is an MIT-licensed, self-hosted tool that monitors HTTP(s), TCP, DNS, ping, push, WebSocket and Docker container targets, and it publishes multiple status pages, each of which can be mapped to a specific domain. The advantage matters when monitoring must run inside your own network, when you want one small tool for both checks and public or internal status, and when your organization is comfortable operating a service. Confirm in your own environment whether the checks you need run from inside the network or only from outside it, because a status page hosted outside the infrastructure it monitors behaves differently during an outage.
Three questions settle most of the decision. First, who receives notifications: if you need a subscriber list with self-managed sign-up, confirm what Uptime Kuma's notification channels can do for your audience, since it supports more than 90 notification services but does not replace a subscriber management product by default. Second, must monitoring run inside your infrastructure: if yes, Uptime Kuma is a natural fit. Third, who operates the tool: if no one on your team will patch, back up and monitor the status host, a hosted service may remain the safer choice. Write these answers down before you request any quote or start a migration.
Which option fits which scenario
This table matches common team situations to the better fit between Atlassian Statuspage and self-hosted Uptime Kuma, with the condition that changes each answer. Read each row as a starting point and check the conditions against your own subscriber volume, network layout and patching capacity before deciding.
| Scenario | Better fit | Reason and conditions |
|---|---|---|
| Small engineering team that wants one tool for monitoring and status | Uptime Kuma | It monitors HTTP, TCP, DNS, ping and Docker targets and publishes status pages from the same install. Holds only if you accept that status pages depend on the same host that runs the monitors. |
| Large subscriber list needing email and SMS at scale | Atlassian Statuspage, or OneUptime after checking delivery | Uptime Kuma's 90-plus notification services are alert channels for your team, not a subscriber list with consent management. Confirm how any self-hosted option delivers bulk email and SMS and who pays the provider. |
| Monitoring inside a private network with no public reach | Uptime Kuma, self-hosted inside the network | It can check internal targets directly from inside the network. Statuspage checks from outside, so it cannot see private services without extra connectivity. Publish the page to a reachable host only if the audience needs it. |
| Several branded status domains for different products or regions | Uptime Kuma | Each status page in Uptime Kuma can map to its own domain on infrastructure you control. Confirm DNS, TLS certificate handling and how many pages your install will serve before you commit. |
| Public status page with formal incident history and scheduled maintenance for customers | Atlassian Statuspage, or OneUptime | Uptime Kuma is built around monitoring and status display, so incident history and maintenance workflows need review against your requirements. Evaluate those features directly in the candidate tools. |
| Team with no one to patch servers or run upgrades | Atlassian Statuspage | A self-hosted Uptime Kuma still needs a host, container updates, backups and a monitoring-of-the-monitor plan. If that work has no owner, the hosted service avoids it. A managed partner can take on the upkeep under a written scope. |
| Regulated organization requiring the status tool to stay in its own accounts | Uptime Kuma, self-hosted | The data, check results and subscriber details remain on infrastructure you operate. Ask your assessor which evidence covers availability, access control and backups for the self-hosted tool. |
| Monitoring must keep working when the monitored infrastructure fails | Atlassian Statuspage or a separate host | A status page on the same servers it reports on can go dark with them. Host the status page outside the monitored environment, whichever tool you choose. |
Where your status data lives and who controls it
Status pages are the one system that must stay reachable when everything else is down, so where they run and who holds the keys matters as much as their feature list. The cards below cover hosting location, outage independence, internal page access and the evidence a compliance review will ask for.
Hosting location of the status page
Atlassian Statuspage is a hosted service, so your public and private pages, subscriber lists and incident history sit on Atlassian's infrastructure under Atlassian's terms. A self-hosted Uptime Kuma instance runs wherever you deploy it, such as your own cloud account or data center. Ask Atlassian which regions store page and subscriber data and what contractual terms cover it, and decide where your own instance will run before you pick a host.
Independence from the monitored systems
A status page hosted inside the same cloud or cluster it reports on can go dark in the same outage it is meant to explain. Uptime Kuma monitors HTTP(s), TCP, DNS, ping and Docker container targets, so placing it in a separate account, region or network keeps monitoring and publication alive when the primary environment fails. Test this by simulating a failure of the production network and confirming the page still updates.
Access control for internal pages
Statuspage private and audience-specific pages gate access through its subscriber model, which is where per-subscriber pricing comes from. With Uptime Kuma, you can place a status page behind your identity provider or a reverse proxy so that only authenticated employees reach it. Confirm how sessions are issued, how group membership maps to access, and who can edit monitors or pages, since the admin account controls both.
Custom domains and certificate ownership
Uptime Kuma lets each status page map to its own domain, so a public page can live on a customer-facing hostname while internal pages stay on a private one. You own the DNS records, TLS certificates and renewal process in this model. Document who holds the DNS zone and certificate keys, because a lapsed certificate on a status page is a visible incident in its own right.
Evidence for compliance readiness
Assessors reviewing incident communication will ask for access logs, change records for monitors and pages, retention of incident history and proof that backups restore. Statuspage provides these as part of a vendor relationship you review through Atlassian's own assurance materials. A self-hosted instance means you produce this evidence yourselves. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications, which come from independent auditors and certification bodies.
Why monitoring from inside your network changes the picture
Uptime Kuma runs its checks from wherever it is installed, so the location of the instance decides what it can see. A hosted status page only reports what reaches it, either because data is pushed to it or because the vendor probes from outside. If your critical services sit on private networks, behind a firewall or on internal hostnames, a Statuspage-style hosted page cannot check them directly. With Uptime Kuma, you place the instance inside the network that holds those services and point its HTTP(s), HTTP(s) keyword, HTTP(s) JSON query, TCP, ping, DNS record or Docker container monitors at internal targets. Before you commit, list every component on your current page and mark which ones are internal-only. Confirm with your network team that the chosen host can reach each of them, and that the monitors you need are among the types listed in the Uptime Kuma repository.
The trade-off is that a self-hosted probe is only as available as the infrastructure running it. If the host, its network segment or its cloud account fails, the monitors stop and the public status page may go stale or show nothing at all, which is the outage your subscribers most need to hear about. For that reason, teams running Uptime Kuma for critical pages often keep a second instance in a different failure domain, or add an external check from a provider that sits outside their own network. Plan that second vantage point as part of the design, not as an afterthought. Decide which monitors must run from both places, how a disagreement between the two is handled, and who gets alerted when the primary instance is silent.
Splitting coverage this way also changes what the status page means. An internal monitor tells you that a service is healthy from inside your network, which can differ from what an customer on the public internet experiences. Where that difference matters, pair an internal check with an external one for the same component and publish the view that matches the audience. Ask your team to document which checks run where, so that the status page's claims can be traced to a specific probe during a post-incident review.
What each option costs to run, and what drives it
Statuspage is a recurring subscription, while Uptime Kuma moves the cost into hosting, delivery and staff time. The cards below separate what you pay a vendor from what you pay your own team, and mark which costs recur.
Statuspage subscription tiers
Atlassian prices Statuspage plans by the number of subscribers, team members and the type of page you run, so the bill grows as your audience and internal user base grow. This is a recurring cost that persists for as long as you keep the service. Before you compare, ask Atlassian for the tier that matches your current subscriber count, your private or audience-specific pages, and the number of people who need editor access, and confirm how each limit is measured.
Uptime Kuma licence fee
Uptime Kuma is released under the MIT license, so there is no license fee to pay for the software itself. The cost you should budget for is the work of deploying it and keeping it current, which is paid to your own staff or an implementation partner rather than to the project. Confirm with your procurement team whether any internal policy requires a review of open-source components, since that review is a one-time activity.
Hosting and backups
Uptime Kuma runs as a single service through Docker Compose or Node.js, so the hosting cost is a server or cloud instance that recurs monthly. Keep it outside the infrastructure it monitors so an outage does not hide itself, and budget for backups of the monitor configuration and status page history. Ask your cloud or data center team what a small, always-on instance costs in your region and where backups are stored.
Notification delivery fees
Uptime Kuma supports more than 90 notification services, including SMTP email, Slack and Pushover, so email and chat alerts often cost little beyond existing contracts. SMS is the main variable: it is billed by your SMS or messaging provider, not by Uptime Kuma. Subscriber notifications on a status page work the same way, so estimate messages per incident and confirm with each provider what a message costs in the countries your subscribers use.
Staff time for upkeep and upgrades
Upgrades are the largest recurring effort. Uptime Kuma 2.5.6 was published on October 9, 2026, and each release needs a test in staging, a backup before the change and a check that monitors and status pages still render correctly. Decide who owns this work and whether it is handled in-house or under a fixed-scope or retainer agreement, and ask any partner for the upgrade and support scope in writing.
Setup and migration effort
Setup is a one-time cost covering installation, mapping components to monitors, configuring custom domains for each status page and telling subscribers about the change. The effort rises with the number of components, the amount of incident history you want to carry over, and the number of subscribers you must re-enroll. Ask for a written scope that lists these items so the one-time figure can be compared with several years of Statuspage fees.
What moving from Statuspage to Uptime Kuma involves
The sequence turns Statuspage components and incident history into Uptime Kuma monitors and status pages on your own domains, with subscribers told about the change before DNS moves. The result is a running, verified status page that your team operates.
Inventory components, incidents and subscribers
Your team exports components, component groups, incident history and subscriber lists from the Statuspage REST API, which is limited to one request per second per token, so pulls should be paced and scripted. Confirm which token scopes your plan grants and where the exported files will be stored, since subscriber lists contain personal data. The step is done when you have a complete, dated export of each page and a count of components that you can check against the Statuspage dashboard.
Map components to Uptime Kuma monitors
Each Statuspage component is matched to a monitor type that Uptime Kuma supports, such as HTTP(s), keyword, TCP, ping, DNS record, push or Docker container. Components that represent manual states, such as planned work or a vendor dependency, may need a push monitor or no monitor at all, and this decision belongs to the service owner. The output is a mapping sheet listing each component, its monitor type, its check target and its owner, reviewed by the people who run those services.
Install Uptime Kuma with Docker Compose
Platform or operations engineers deploy Uptime Kuma inside your own infrastructure using the louislam/uptime-kuma:2 image through Docker Compose, which keeps the configuration in a file you can version. Place it on a network segment that can reach the services it monitors, and decide whether it also needs to reach external targets for public checks. The step closes when the container runs, the web interface loads over the internal address and the data volume survives a restart.
Build monitors and status pages per domain
Engineers create the monitors from the mapping sheet and group them into status pages. Uptime Kuma supports multiple status pages and maps each one to a specific domain, so a public page and an internal page can be separate pages with separate domains and the same monitors. Confirm TLS certificates and DNS records for each domain before you point customers at it. The step is done when each page shows the expected components, and every monitor reports a status that matches what your engineers see on the service.
Decide and send subscriber notice
Subscribers on Statuspage hold their own notification settings, and those do not transfer automatically. Decide whether to re-subscribe users, import addresses only where you hold a lawful basis and consent records, or send a notice asking people to subscribe on the new page. Uptime Kuma can notify through more than 90 services, including SMTP email, Slack and Telegram, so confirm which channels you will run and who operates the mail relay. The step closes when the notice has been approved by your communications and privacy owners and sent.
Run both status pages in parallel
For a period agreed in your change plan, the Statuspage page and the Uptime Kuma page stay live together, and your incident team posts updates to both during that window. This surfaces gaps such as a component that never turns red during a real degradation or a monitor that flaps on a slow endpoint. The output is a short log of discrepancies, each with an owner and a fix, and a sign-off from the incident commander that the new page reports accurately.
Switch DNS and retire the old page
Once parallel running is signed off, your DNS owner points the public hostname to the Uptime Kuma host and removes or redirects the Statuspage custom domain. Confirm the cutover in a maintenance window, verify the certificate and page load from outside your network, and keep the Statuspage export and a read-only record of the old page for audit and customer questions. The step is done when the public hostname resolves to the new page and the old one no longer serves traffic.
What you give up when you leave a managed status page
The main thing you give up when you leave Statuspage is a dedicated status product with a mature subscriber model. Uptime Kuma is first a monitoring tool that also publishes status pages, and its subscriber handling is lighter than what a hosted status product offers. Before you commit, confirm in a test instance how subscriber sign-up works, whether it supports double opt-in confirmation, how unsubscribe requests are handled, and whether a subscriber can choose which components or incident types to receive. Also confirm whether incident-specific update flows exist, such as posting an investigating, identified and resolved update to one incident and having it reach subscribers in the right order. If your current process depends on those flows, document them as requirements and test each one against your planned configuration.
Recurring upkeep moves to your team or to a DeployOpen retainer. On Statuspage, the vendor runs the hosted service, its delivery infrastructure and its availability. On Uptime Kuma, you own the container host, the database volume, TLS certificates for each custom domain, the image upgrade cycle and the backup routine. Decide who applies upgrades (the current release line is louislam/uptime-kuma:2), who watches the status page host itself, and what happens during an outage of your own infrastructure, since a status page that depends on the systems it reports on is a poor fit for that job. Ongoing support, upgrades and continuous testing can be covered by a DeployOpen retainer, which is agreed in writing against a defined scope.
Questions buyers ask before moving status pages
How much effort does moving from Statuspage to Uptime Kuma take?
The effort depends mostly on how many components, monitors and historical incidents you need to carry over, and on how many status pages and custom domains you run. Uptime Kuma needs a monitor for each service you want to report on, so every Statuspage component must be mapped to a check that reflects its real health. Teams with a small set of components and a clear owner for each service usually finish this faster than teams with many manually maintained components. Ask your implementation partner to inventory components, subscribers, domains and incident history before agreeing on a scope. The inventory is what turns a vague estimate into a defined piece of work.
Can our team self-host Uptime Kuma without outside help?
Yes, many teams do, because Uptime Kuma is MIT licensed and installs with Docker Compose or a single docker run command using the louislam/uptime-kuma:2 image. It can also run without Docker on Node.js 20.4 or later with Git, optionally managed by pm2. The harder work is around the install: mapping components to monitors, setting up notification channels, configuring a custom domain per status page, and deciding how the host itself is backed up and patched. Outside help is most useful where those decisions touch your identity, network or compliance controls. Confirm internally who will own the host, its updates and its alerting before deciding.
How much staff time does a status page migration need?
Staff time falls into three groups: people who own the services and confirm which monitors represent them, an engineer who runs the install and migration, and a communications owner who writes the subscriber notice and approves the cutover. Your time is driven by how well documented your services are and how many teams must sign off on component wording. Plan for a review cycle on the status page text, since it is publicly visible during incidents. Ask any provider to state in writing which of these roles it covers and which fall to your staff, so the internal commitment is clear before work starts.
Do subscribers have to re-consent when we move status pages?
Confirm this with your legal or privacy team before you export anything, because the answer depends on how subscriber data was collected and what your notices promised. Statuspage subscribers have opted in to receive updates from a specific page, and moving their addresses to a new system is a processing change that needs a documented basis. Many teams choose to notify subscribers of the new page and invite them to resubscribe rather than carry lists across. Whatever you decide, keep a record of the lawful basis and the notice you sent. Uptime Kuma sends notifications through its supported channels, including SMTP email, so plan which channels subscribers will receive updates on.
How does DeployOpen scope a fixed-scope status page engagement?
Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. For a status page move, the scope usually covers the component and monitor mapping, the Uptime Kuma deployment in your infrastructure, custom domain setup for each status page, data export and import where it is in scope, and the subscriber cutover plan. Ongoing support, upgrades and continuous testing are available as separate retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for the deliverables list, the assumptions behind it and what changes are needed if the component count grows.
Can Uptime Kuma replace Statuspage private pages behind SSO?
Uptime Kuma supports multiple status pages, and each can be mapped to a specific domain, so you can publish an internal page on a domain only your staff can reach. Statuspage's private and audience-specific pages are priced by authenticated subscriber, while a self-hosted page is not priced that way. Whether an internal page sits behind your identity provider depends on how you front the host, for example with a reverse proxy that enforces single sign-on. Confirm this design with your security team and test that access is denied to anyone outside the intended group before you rely on it.
What does our team need to supply for the migration?
The team needs to supply a current list of components and the services behind them, access to the Statuspage account for export, the domains and DNS control for each status page, and a named owner for notification channels. You also need access to the hosts or cloud accounts where Uptime Kuma will run, and a decision on which incident history to keep. Services that cannot be monitored by HTTP, TCP, ping, DNS, push or Docker checks will need an agreed alternative. Gathering these before scoping shortens the discovery phase and makes any written quote more accurate.
What should we check if a monitor reports the wrong status?
Start by confirming the monitor type matches the service, since a TCP check can pass while an application is failing. Uptime Kuma offers HTTP(s) keyword and HTTP(s) JSON query monitors for cases where a status code alone is not enough. Next, check the notification routing so the right channel receives the alert, and confirm the check interval and retry settings suit the service. Compare the status shown on the public page with the monitor history during a test incident. Document these checks in your runbook so a later change does not quietly break a component.
How DeployOpen helps you decide and move
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. If you are weighing Atlassian Statuspage against Uptime Kuma, the practical question is who will operate the status page and the monitors that feed it once the hosted service is gone. DeployOpen can answer that for you by mapping your current components, subscriber groups and custom domains to Uptime Kuma monitors and status pages, then deploying them where your team can keep them running. DeployOpen is not a vendor partner or reseller for Uptime Kuma, and we do not claim any partnership status with it.
Most engagements are fixed-scope. Before any work starts, we agree the scope, deliverables and timelines in writing, which typically covers the component inventory, the monitor design, the domain and TLS setup for each status page, the notification channels for subscribers and internal responders, backup of the Uptime Kuma data, and the cutover plan. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move it are the number of components and status pages, the notification services you need, whether private pages must sit behind your identity provider, and how much of the runbook your team wants us to write. Ask for each of these to be itemized so you can compare a quote with your own effort estimate.
Once the status page is live, the work does not end. Uptime Kuma upgrades, certificate renewals, backup checks and changes to monitors are ongoing tasks, and DeployOpen offers retainers for ongoing support and upgrades if your team does not want to carry them alone. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so if your status page history or access logs feed an assessment, confirm with your auditor which records they will accept. Request a scope conversation to test your component list against Uptime Kuma before committing to either path.
