Open-source alternative to PagerDuty Status Pages: the short answer
If your team wants customer-facing incident communication on infrastructure it controls, the two main self-hosted options are Uptime Kuma and OneUptime. Uptime Kuma is MIT licensed, supports multiple status pages, and lets each page map to a specific domain, which covers public status communication well. OneUptime's Community Edition is Apache 2.0 with the ee/ directory under its enterprise license, and it links status pages to incident history, scheduled maintenance and subscriber notifications, so updates can be tied to the incident that caused them. Neither tool replaces PagerDuty's full incident response suite on its own, so the deciding question is whether your status updates must be generated from incident records or can be published by hand.
Start by listing what your current PagerDuty status pages do today. If customers only need a page showing component health, planned maintenance and a free-text incident notice, Uptime Kuma is a small, low-effort fit that you can run with Docker Compose. If responders should declare an incident once and have the status page, subscriber emails and post-incident notes update from that record, OneUptime is the closer match, but it means operating a larger stack. Confirm which subscriber channels you use today, including email, SMS and webhooks, and check each candidate against that list, since notification coverage differs by product. The Uptime Kuma repository and the OneUptime repository document the current feature set.
Which PagerDuty status page capabilities map to which open-source option
This table maps the status page capabilities teams usually rely on in PagerDuty to Uptime Kuma and OneUptime Community Edition. Read each row as a fit check: items stated in project documentation are confirmed, while items marked to confirm need checking against the current release notes before you commit to a design. Both tools are self-hosted, so the main question is how much incident workflow your public and internal pages need.
| Capability | Uptime Kuma | OneUptime Community Edition |
|---|---|---|
| Public status page | Multiple status pages supported, each mappable to a specific domain | Branded public status pages included |
| Private status page for internal users | Confirm whether access restriction is available in your release | Branded private status pages included |
| Component status | Shows status of monitored services; confirm grouping and display options | Confirm the component model and how components link to monitors |
| Incident updates | Confirm whether incidents can be posted to the page | Incident management covers declaring, assigning, communicating and resolving incidents |
| Incident-to-status linking | Confirm whether an incident can change page status automatically | Confirm in current release notes whether incidents update component status |
| Scheduled maintenance | Confirm availability in your release | Included in Community Edition status pages |
| Subscriber notifications | Confirm subscriber sign-up and channels; admin alerts support more than 90 services | Included; confirm supported subscriber channels in current release notes |
| Custom domains | Each status page can be mapped to a specific domain | Confirm custom domain setup for Community Edition in current docs |
| SSO for internal pages | Confirm; not established from project facts | SAML and OIDC sign-in included; confirm it gates private status pages |
| Incident history | Confirm history display on pages | Incident history included on status pages |
Uptime Kuma or OneUptime: which fits which status page need
Uptime Kuma and OneUptime both publish self-hosted status pages, but they start from different places. One is a lightweight monitor that grew a status page, the other is an incident-linked platform that also covers on-call. The cards below help you match the tool to the page you need to replace.
Uptime Kuma as a monitoring-led page
Uptime Kuma is MIT licensed and built around uptime checks. It monitors HTTP(s), keyword and JSON query targets, TCP, ping, DNS records, WebSocket, push and Docker containers, and it supports more than 90 notification services such as Slack, Discord, Telegram, Pushover and SMTP email. Each status page can be mapped to its own domain. This fits teams whose public page mainly reflects what monitors detect. Check whether you need incident write-ups, scheduled maintenance or subscriber notifications tied to a formal incident record, because those are not its focus.
OneUptime as an incident-linked platform
OneUptime's Community Edition is Apache 2.0 licensed, with the ee/ directory under its Enterprise License. It includes branded public and private status pages with incident history, scheduled maintenance and subscriber notifications, and it connects those pages to incident declaration, assignment, resolution and post-mortems. This suits teams whose status page must reflect the incident workflow. Confirm which parts of that workflow your responders will actually use before retiring PagerDuty features that depend on it.
Install and operating effort
Uptime Kuma runs from a single docker run command or Docker Compose file using the louislam/uptime-kuma:2 image, or on Node.js 20.4 or later with Git, optionally managed by pm2. OneUptime self-hosts with Docker Compose on one Debian, Ubuntu or RHEL server, and the project recommends a Helm chart for production. Its footprint covers more services, so budget more time for upgrades, backups and monitoring of the platform itself. Ask your team who will own each upgrade cycle before choosing.
Enterprise-only controls to plan for
OneUptime's Community Edition includes SAML and OIDC single sign-on. SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency sit in the Enterprise Edition, which is priced through sales. Teams with identity lifecycle, audit or data residency requirements should request a written quote for those features early. Uptime Kuma has no equivalent enterprise tier to compare against, so review its access controls and logging against your own requirements.
Keeping PagerDuty for alerting
Some teams keep PagerDuty for on-call escalation and move only the public page. In that setup, the status page is decoupled from paging: Uptime Kuma or OneUptime publishes status and maintenance notices while PagerDuty remains the system that wakes responders. Confirm that the status page tool can still receive your incident updates by hand or through an integration, and document who posts updates during an outage so the public page does not lag behind the alerts.
Running the status page alongside PagerDuty alerting
In this situation your engineers keep receiving alerts and running incidents in PagerDuty, and only the public and private status page moves to a self-hosted product. The status page is then a consumer of incident information rather than the system that pages people. Updates still have to be copied or pushed from PagerDuty into the new page, so the integration path becomes the critical piece to design.
- Manual posting: An incident commander writes the status update directly in Uptime Kuma or OneUptime. This is the lowest technical risk but depends on a person remembering to update both places.
- API or webhook push: A script or small service receives PagerDuty incident events and calls the status page API to create or update an incident. Confirm which PagerDuty webhook or event types you can subscribe to in your account and which status page API endpoints your product version exposes.
- Monitor-driven status: Uptime Kuma can change a component state when its own monitors fail, which covers simple availability signals without touching PagerDuty at all.
- Ownership of the incident record: PagerDuty remains the source of truth for timelines and responders, so define which system wins when the two disagree.
Confirm the exact integration path in the documentation for the product version you run, because webhook support and API coverage differ between releases.
In this situation the paging, escalation and status page move at the same time, usually to OneUptime, which includes on-call schedules, escalation policies and public status pages in one Community Edition product. Because the incident record and the public page live in the same system, the status page can be updated from the incident itself without a separate integration. The risk moves to cutover planning, since every team that depends on PagerDuty must switch its alert sources and responders in one coordinated window.
- Single incident object: Declaring an incident in OneUptime can drive the status page entry, subscriber notifications and the timeline, which removes most of the copy work.
- Alert channels: Confirm that the SMS, phone call, push, email and Slack paths you need are configured and tested for every responder before PagerDuty is disabled.
- Component mapping: Rebuild the list of public components and map each one to the monitors that drive it, so the page reflects the same services customers recognize.
- Custom domains: Plan the DNS change for the status page hostname and its certificate in advance, so subscribers see no break.
- Fallback window: Keep the previous status page reachable until the new one has handled at least one real or scheduled maintenance event.
Confirm the notification and status page features against the OneUptime release you deploy, since the Community Edition scope is documented in the project repository.
Running both systems for a period is the safest route when several teams depend on PagerDuty, but it creates a dual-write problem: one incident can produce two pages, two timelines and two sets of subscriber messages. The usual approach is to decide, per incident class, which system is authoritative and to let the other receive only what it needs. Treat the parallel period as a controlled test with a defined end date agreed by the operations and communications owners.
- Authority rules: Decide which tool opens the incident, which tool publishes the public update and which tool sends internal paging during the overlap.
- Duplicate suppression: Prevent subscribers from receiving the same message from both status pages, for example by keeping only one public page live at a time.
- Test incidents: Run scheduled test incidents through both paths and compare the time to a published update, the wording and the subscriber delivery.
- Retirement checklist: Record the date each PagerDuty integration is removed, the status page redirect is set and access to historical incident records is preserved.
- Audit trail: Keep the record of which system published each update, since reviewers will ask how public communication was controlled during the change.
Confirm how each product's API and webhook behavior works in the version in use before you rely on it for automation during an outage.
How custom domains and subscriber notifications work on a self-hosted page
Mapping a status page to a company domain on a self-hosted tool is a DNS, TLS and reverse proxy task, and the work sits with your team. Uptime Kuma supports multiple status pages, each of which can be mapped to a specific domain, so you point a DNS record such as status.example.com at the host that serves the page. OneUptime's status pages are branded and hosted by the same self-hosted deployment, so the same DNS and certificate steps apply. Before you start, confirm which hostname each status page will use, who controls the DNS zone, and whether the reverse proxy in front of the tool terminates TLS. Issue the certificate for the exact hostname, configure the proxy to forward it to the tool, and test the page from outside your network, since an internal-only test can hide a missing public record. Confirm the domain mapping and certificate renewal with the tool's current documentation for your version, because the exact settings change between releases.
Subscriber notifications are delivered through each tool's notification channels, and the tools differ in what they support. Uptime Kuma supports more than 90 notification services, including SMTP email, Slack, Discord, Telegram and Pushover, so you can notify subscribers through the channels you already operate. OneUptime's Community Edition sends subscriber notifications for incident history and scheduled maintenance, and its on-call alerts reach responders by SMS, phone call, push, email and Slack. Confirm, for each tool, which channels can notify external subscribers as opposed to internal responders, and whether subscribers can self-enroll and unsubscribe.
The sending service is a component your team owns, and it must be confirmed before go-live. Email subscriptions depend on an SMTP provider or relay that you select, configure with SPF, DKIM and DMARC records for your domain, and monitor for bounces. SMS or voice subscriber messages depend on a gateway with its own sender registration rules and per-message charges. Ask whoever runs the mail and messaging accounts to confirm sending limits, the sender identity subscribers will see, and who is paid for each message, because those costs and limits recur for as long as the page is live.
Moving PagerDuty status page content to a self-hosted page
This sequence moves your public status components, incident history and subscriber relationships from PagerDuty to a self-hosted page on your own domain, with a parallel run before DNS changes. The output is a verified status page that your customers reach without depending on PagerDuty.
Inventory components, incidents and subscribers
The platform owner lists every public and private status page, each component and group, the current incident history, and any scheduled maintenance still on the calendar. Ask PagerDuty support or check your plan's admin pages to confirm whether subscriber contact details can be exported and in what format, because subscriber data may not transfer automatically. The step is done when you hold a written inventory that a second engineer has reviewed and that names each component's owner.
Confirm subscriber export with PagerDuty
Before any build work, the communications lead asks PagerDuty support in writing whether subscriber email addresses, phone numbers and webhook endpoints can be exported on your current plan, and under which format and limits. If export is not possible, record that answer and plan for customers to re-subscribe on the new page, with a notice you send through channels you already control. The step is done when the answer is filed with the migration record and the subscriber plan is agreed.
Rebuild components and monitors in the new tool
The platform team recreates the component tree in Uptime Kuma or OneUptime, choosing Uptime Kuma for simple HTTP, TCP or keyword checks that map to a status page, or OneUptime when you also need incident management, scheduled maintenance and subscriber notifications in the same product. Each component is linked to a monitor that represents its real health, and the team recreates historical incidents as read-only entries where they matter to customers. The step is done when every component shows a live status and the incident list matches the inventory.
Configure custom domain and TLS
The infrastructure team points a staging hostname at the new status page, maps it to the page in the tool's settings, and issues a valid TLS certificate for that hostname through your existing certificate process. Uptime Kuma supports mapping a status page to a specific domain, and OneUptime's status pages are configured in its own settings, so confirm the exact steps in the version you run. The step is done when the staging hostname loads over HTTPS with a certificate that clients trust.
Run a parallel page on the staging domain
For a defined period agreed by the incident and communications owners, both pages run side by side and the team posts a test maintenance notice and a test incident on the staging page only. The on-call lead confirms that the new page updates when a monitor changes state and that subscriber notifications go out to a test list. The step is done when the test incident, its resolution and the notification path have each been checked against a written checklist.
Switch DNS to the self-hosted page
The DNS owner lowers the record's TTL in advance and then changes the public hostname to point at the self-hosted page during a window agreed with incident management. Once the change propagates, a checker outside your network loads the page and compares its components with the inventory. The step is done when the public hostname resolves to the new page, the old PagerDuty page is no longer the source for that name, and the rollback path is documented.
Retire the PagerDuty page after notice
The communications lead publishes a notice on the old page and in your existing customer channels that the status page has moved and where subscribers should now go. The old PagerDuty page stays available for the notice period you set, then the platform owner disables it or removes the subscription that carries it, after confirming that no other integration still depends on it. The step is done when the notice is archived, the old page is disabled, and the migration record notes the final date.
Questions buyers ask before replacing PagerDuty status pages
What does it cost to run a self-hosted status page?
Running a self-hosted status page costs the infrastructure it sits on, the time your staff spend operating it, and the notification channels you choose. The main components are hosting (a virtual machine or container host), a database if you choose OneUptime, which runs several services, a domain name with TLS certificates, and a notification gateway such as SMTP email, SMS or a chat webhook. Hosting and certificates are usually small recurring line items, while staff time is the largest cost and recurs with every upgrade and incident. Ask any vendor or partner for a written quote that separates one-time setup from monthly operating costs, and ask which notification services carry per-message charges. Your own cloud pricing and mail or SMS contracts will set the actual figures.
How long does it take to move status pages off PagerDuty?
The timeline depends mostly on how many components, services and subscribers you have, how many domains need to move, and how many notification channels must be rebuilt. Uptime Kuma can be deployed quickly with a single container image, but mapping each monitor to a public component, setting up custom domains and re-creating subscriber lists takes more time. OneUptime takes longer because it runs several services and needs its incident, on-call and status page modules configured together. Other drivers include the number of approval steps for DNS changes, whether you run a parallel period where both pages show the same incidents, and how much incident history you need to carry over. Agree the timeline in writing once the scope is defined.
Can our own team replace PagerDuty status pages without outside help?
Yes, a team with Linux, Docker and DNS experience can deploy Uptime Kuma alone, and many teams do. The harder parts are design and operations: deciding which components customers see, writing incident wording, testing subscriber notifications, and keeping the page reachable during an outage that affects your main environment. Those tasks need a named owner inside your organization. Outside help is most useful for planning the cutover, hardening the server, setting up backups and monitoring of the status page itself, and documenting the runbook. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written scope, so you can decide which parts to keep in-house.
What access and accounts does the migration require from our side?
The migration needs DNS access to point your status domain at the new host and to issue certificates, an account with your email provider or an SMTP relay for subscriber emails, and optionally SMS or chat accounts for other notification channels. You also need a named owner who defines which services appear as components, approves wording for incidents and maintenance, and signs off on the cutover. Access should be scoped to the minimum needed, with credentials stored in your secrets manager rather than in configuration files. Confirm early whether your email provider limits bulk sending, since subscriber notifications depend on that limit.
Is the Community Edition of OneUptime enough for public status pages?
For many teams, the Community Edition covers the core needs: branded public and private status pages, incident history, scheduled maintenance and subscriber notifications. It is licensed under Apache License 2.0, except the ee/ directory, which falls under the OneUptime Enterprise License. The Enterprise Edition adds SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency, and its pricing is set through sales. Check whether your compliance program needs audit logs or SCIM before choosing the Community Edition, and confirm current feature coverage against the project repository, since features change between releases. Uptime Kuma is a lighter option, MIT-licensed, and suits teams that need a status page and uptime checks without incident management.
How do we keep the status page and its software up to date?
Keeping a self-hosted status page current involves two streams: the content, meaning components, incidents and maintenance notices, and the software itself. Content updates should follow your incident process, with a named person responsible for posting and closing incidents during an outage. Software updates require reading release notes, testing in a non-production instance, taking a backup, and scheduling a window. Uptime Kuma publishes releases on GitHub, and version 2.5.6 was published on October 9, 2026, while OneUptime's release page lists 14.0.70 published on October 18, 2026. Subscribe to those release feeds, and agree in your support arrangement who applies patches and how often. Ongoing upgrades and testing can be covered by a retainer.
What happens to status pages if our main environment goes down?
A status page is only useful during an outage if it is hosted separately from the systems it reports on. Place the status page on a different network, provider or region from your production workloads, and use a separate DNS and certificate process so that a failure in one does not remove the other. Confirm that the paging path used for the status page owner does not depend on the same infrastructure. Test failover by taking the production environment offline in a rehearsal and posting an incident from the backup path. This design work is part of the scope agreed before implementation.
What a status page replacement does not replace
Moving status pages does not move PagerDuty's wider incident response work. A status page publishes what customers see, but it does not route alerts, choose responders, run the bridge call or keep the timeline of a major incident. Before you cancel anything, list each PagerDuty capability your teams use during an outage and assign it a destination. Items to check include event grouping or AIOps features, runbook automation, incident timelines, stakeholder updates and post-incident reviews. Confirm each one against the current PagerDuty documentation for your plan, because packaging differs between add-ons and platform tiers.
OneUptime covers the most ground in a single self-hosted product. Its Community Edition includes incident management from declaration through post-mortems, on-call schedules and escalation policies, and branded status pages with incident history and subscriber notifications. Uptime Kuma is narrower. It monitors targets, sends notifications to more than 90 services and maps status pages to specific domains, but the supplied material does not show it managing incidents or on-call. If you choose Uptime Kuma for public status, plan a separate incident tool for responders. Confirm which OneUptime features need the Enterprise Edition before you commit to a licensing path.
For the on-call question, read the sibling comparisons PagerDuty vs OneUptime and PagerDuty vs GoAlert, which cover schedules, escalation and paging channels in detail. Decide the paging system first, because the status page depends on it: whoever is paged must also be able to update the page. Write down who owns the public update during an incident, which template they use and how long the page can go without a message. Test that path in a drill. If AIOps or runbook automation matter to your teams, keep PagerDuty for those functions and set a dated review of that decision.
How DeployOpen scopes and delivers a self-hosted status page
DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted status pages inside your own infrastructure. For a PagerDuty Status Pages replacement, we start from the written scope, which sets which page is built, which incident sources feed it and which subscriber channels are switched on.
How we scope
- Inventory the components, services and regions that the public and private status pages must show.
- Decide between Uptime Kuma for simple monitor-driven pages and OneUptime for incident history and scheduled maintenance.
- Record the custom domains, subscriber channels and single sign-on requirements for private pages in the written scope.
How we build
- Deploy the chosen platform in your cloud account, data center or air-gapped network using the supported install method.
- Map each status page to its domain and configure the monitors, incidents and notification channels that feed it.
- Test incident publishing, subscriber notifications and failover of the page against a set of agreed scenarios before go-live.
How we hand over
- Document the configuration, component mapping, runbooks for publishing incidents and the backup and upgrade procedure.
- Walk your operations and communications staff through posting updates so they can run the page without us.
- Provide the evidence and configuration records your compliance and audit teams need, without issuing any attestation.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, platform upgrades and continuous testing are available as a retainer after handover.
- Ask for a quote built from the written scope, and confirm the platform version and hosting model you need before signing.
