Self-hosted alternative to Statuspage private pages

Why internal status pages should sit behind your own SSO

Operations, IT and security leads need staff to see service status without publishing it to the internet and without adding every employee as a paid subscriber. The short answer is to host the status page yourself and put it behind your own login. A self-hosted OneUptime private page or an Uptime Kuma status page, each placed behind your identity provider, lets your existing directory decide who can view it. Access then follows the same joiner, mover and leaver process you already run for other internal systems. This section uses Keycloak as the example identity provider because it is open source, supports OpenID Connect and SAML 2.0, and is widely deployed in self-hosted environments.

Statuspage's private and audience-specific pages are priced around authenticated subscribers, so the cost of showing status to staff grows with headcount. Before you compare options, confirm the current tiers, subscriber allowances and add-on charges directly with Atlassian's current pricing, because no figures for this comparison have been verified for this page. Ask Atlassian in writing how it counts internal viewers, whether SSO or SAML is included in your tier, and what happens to access when you exceed a plan limit.

The main design choice is where authentication happens. OneUptime's Community Edition includes SAML and OIDC single sign-on, so you can connect it to Keycloak directly. With Uptime Kuma, the status page itself has no identity layer of its own in this comparison, so you would place it behind a reverse proxy or access gateway that enforces Keycloak login before any request reaches the page. Confirm with each project's current documentation whether the page can run unauthenticated for internal use and whether a proxy-based approach meets your policy. Test the login flow, group-based access and session timeout with a small set of accounts before you publish the URL to staff.

What an internal status page behind SSO has to enforce

An internal status page shows incident state and internal dependencies to staff, so it inherits the same access controls as any internal system. The six requirements below connect the identity provider, the status platform and the surrounding network, and each one names what to verify before you rely on it.

Access limited to authenticated employees

The page must refuse anonymous visitors, including search engines and former contractors. Decide whether the page sits on a private hostname reachable only through the corporate network or VPN, or on a public hostname that forces login at the edge. Confirm how each candidate handles unauthenticated requests, redirects and cached copies, since a page that renders its last state without a session leaks the same information as an open one.

Login delegated to the identity provider

Employees should sign in with the same identity provider that governs email and cloud consoles, so MFA and conditional access apply. OneUptime's Community Edition includes SAML and OIDC single sign-on. Uptime Kuma does not provide its own SSO in the facts supplied here, so plan a reverse proxy or an SSO gateway in front of it and confirm how group membership is passed through.

Separate internal and public audiences

Internal incident detail, such as affected internal tools or named owners, should not reach the public page. Use separate status pages with separate components and separate subscriber lists. Confirm whether the platform can publish a component to one audience only, and whether subscriber notifications for internal pages are sent only to verified corporate addresses.

Custom domain and reverse proxy placement

Uptime Kuma supports multiple status pages, each mapped to a specific domain, which lets an internal page sit on a hostname such as an internal-only name. Put the TLS termination, the SSO check and the access logs in one place. Verify that the proxy forwards the identity headers the platform expects and that WebSocket traffic, which the status page depends on, passes through the proxy correctly.

Audit trail of status changes

Every status change, incident update and maintenance window should record who made it and when. Ask each candidate for an audit log of administrative and incident actions. OneUptime lists audit logs under its Enterprise Edition, so confirm whether your needs can be met by the Community Edition or by an exported log stored in your SIEM. Uptime Kuma's audit capabilities should be verified against the release you deploy.

Removal of access when staff leave

Access should follow the identity provider, so disabling an account there ends access to the page without a second change. Check whether sessions expire on the platform side and how long a valid token remains usable after deactivation. For OneUptime, SCIM provisioning appears in the Enterprise Edition, so confirm how group removal is handled on the Community Edition and document a recurring access review.

Where per-subscriber pricing pushes internal status pages toward a cost problem

Statuspage prices private and audience-specific pages by authenticated subscriber, so the bill follows the number of people who sign in to see internal status, not the number of incidents you publish. For internal status, that is often the whole workforce. Every employee who needs to know whether the VPN, the build system or payroll is up is a potential subscriber, and headcount growth raises the count even when the page itself never changes. Other drivers move the bill as well: how many audiences you run (a separate page for each department, region or customer group adds viewers to track), how many team members hold editing rights, and whether one page is split into several. Splitting pages changes how viewers are counted, so model the layout before you decide it.

Renewal is where these drivers become visible. Pricing tied to people means a hiring quarter, a reorganization or a new audience can change the invoice without any change to how the service runs. Before you negotiate, ask Atlassian to confirm in writing: the current plan names that include private and audience-specific pages; the exact definition of a subscriber, including whether an employee who signs in once, or an address on a distribution list, counts; how restricted pages are billed compared with public pages; which team members count as editors; and what changes at renewal, including list price movement, changes to included seats and any true-up charged for seats above the committed level. Keep the answers on file so your comparison uses the same audience counts.

Model the same audience on a self-hosted option before you decide. The OneUptime repository documents private status pages in its Community Edition, along with SAML and OIDC single sign-on, so employees can authenticate with your identity provider. Uptime Kuma can serve a status page on a domain you control, and you can place it behind your identity provider with a reverse proxy, but confirm the exact setup in the project documentation and test it with your own groups. Your costs then shift to hosting, email and SMS delivery, and upkeep, which you should price from your own environment and staffing rather than from any vendor figure.

Which open-source option fits employee-only status pages

This table compares OneUptime and Uptime Kuma as options for internal status pages that only employees can open. Read each row as a requirement: what the platform gives you, what you must add in front of it, and where the trade-off sits. The main takeaway is that OneUptime covers SSO natively in its Community Edition, while Uptime Kuma needs an enforced login layer unless its current release proves otherwise.

Requirement	OneUptime	Uptime Kuma
Private status page	Community Edition includes branded private status pages with incident history and scheduled maintenance, so employee-only pages sit in the same tool as public ones.	Supports multiple status pages, each mapped to its own domain, but the private page is not a native access-controlled audience feature. Put it behind a login layer.
Single sign-on for employees	Community Edition includes SAML and OIDC single sign-on, so employees can sign in with your identity provider such as Keycloak.	Native SSO is not listed in the supplied facts. Confirm it against the current release, and if absent, enforce login at a reverse proxy.
Per-subscriber pricing	No per-subscriber pricing is listed for self-hosting. Your cost is hosting, upkeep and any email or SMS delivery you configure.	No per-subscriber pricing is listed for self-hosting. Your cost is hosting, upkeep and any notification services you configure.
Automated SCIM user provisioning	Listed only in the Enterprise Edition, priced through sales. Community Edition relies on manual account handling.	Not listed. Joiner and leaver access must be handled by your identity provider group rules at the proxy layer.
Audit logs and compliance evidence	Audit logs, compliance dashboards and instance health dashboards are Enterprise Edition items. Confirm what Community Edition records.	Not listed in supplied facts. Collect access logs from the reverse proxy and identity provider as evidence.
Monitoring behind the status page	Monitors websites, APIs, ports, SSL, DNS and synthetic checks, and ingests telemetry through OpenTelemetry-based agents.	Monitors HTTP(s), TCP, keyword, JSON query, DNS, ping, push and Docker container targets. Lighter scope than OneUptime for internal services.
Deployment footprint	Self-hosts with Docker Compose on one Debian, Ubuntu or RHEL server, or with the Helm chart the project recommends for production.	Installs with Docker Compose or a single docker run command, or runs on Node.js 20.4 or later. Smaller footprint to operate.
Licensing	Community Edition is Apache License 2.0, except the ee/ directory under the OneUptime Enterprise License. Check which directories you deploy.	MIT licensed as a whole, which keeps the license review simpler for internal use.

Choosing OneUptime or Uptime Kuma by what the page must do

If your employees need a private page that reflects live incidents, scheduled maintenance and escalation, OneUptime is the better fit because it covers incident management and on-call in the same system as the status page. Incidents are declared, assigned and communicated from one place, and on-call schedules with escalation policies send alerts by SMS, phone call, push, email and Slack. The operational load is higher: you run a multi-service application, and the project offers Docker Compose on a single Debian, Ubuntu or RHEL server, with a Helm chart it recommends for production.

Upkeep: Plan for regular upgrades of a larger stack, and confirm the release cadence and upgrade notes in the OneUptime releases before you commit.
Who edits incidents: Responders and incident commanders update status directly, so define which roles can publish to the private page.
Where SSO is configured: SAML and OIDC single sign-on are in the Community Edition, so configure them in OneUptime itself and test group mapping for on-call roles.
Enterprise features: SCIM provisioning, audit logs and data residency are Enterprise Edition items priced through sales, so confirm whether you need them before design.
Alerting delivery: Confirm SMS and phone call providers and their costs with your own telecom and vendor agreements.

Before choosing, confirm that your required alert channels and private page audiences work in your own test instance.

How to deploy a private status page behind your identity provider

This sequence takes a private status page from an agreed audience list to a tested, documented deployment that only signed-in employees can open. It ends with a page that authenticates through your own identity provider and a rollback path your operations team can run.

Confirm the audience and access constraint
Start with the owner of the status page, the security lead and the identity provider owner. Agree on which groups should see the page, whether any content is restricted by audience, and which pages must stay public. Record the answers as a short written scope. This step is done when every group that needs access is named, the editors are listed separately from viewers, and the identity provider owner has confirmed that the groups exist or will be created.
Deploy the identity provider in your infrastructure
If you do not already run an identity provider you control, deploy Keycloak, which is licensed under Apache 2.0, inside your own cloud account, data center or air-gapped network. Use a supported production database such as PostgreSQL 14 to 18, not the development file database. Confirm the Keycloak release you will run against the current release notes and your change policy. This step is done when the administration console is reachable only from your management network and a test realm exists.
Register the status page as an OIDC or SAML client
In the identity provider, create a client for the status page. OneUptime's Community Edition supports SAML and OIDC single sign-on, and Uptime Kuma's page access should be fronted by the proxy in the next steps, so register the client that matches your chosen design. Set the redirect URI to the exact status page domain, map a group claim to the viewer and editor roles, and restrict the client to the groups agreed in the first step. This step is done when a test user in the viewer group receives a token and a user outside those groups is refused.
Deploy OneUptime or Uptime Kuma
For a single status page that also includes incident history, scheduled maintenance and subscriber notifications, deploy OneUptime with Docker Compose on a supported Debian, Ubuntu or RHEL server, or with the Helm chart that the project recommends for production. For a lighter setup that monitors services and publishes status pages from one tool, deploy Uptime Kuma with the louislam/uptime-kuma:2 image. Confirm the current release notes before pinning a version. This step is done when the application starts, the admin account works and the private page is created but not yet published.
Place the page behind a reverse proxy and certificate
Publish the status page under the domain agreed with the DNS owner, and terminate TLS at a reverse proxy with a certificate issued by your internal or public certificate authority. Route only the status page hostname to the application and make sure the admin interface is on a separate path or hostname that is not reachable from the internet. Coordinate the DNS record and the certificate renewal process with the infrastructure team. This step is done when the page loads over HTTPS on the chosen hostname and an unauthenticated request is redirected to the identity provider.
Test login with a non-admin account
Sign in as an ordinary employee from the viewer group, not as an administrator, and confirm that the page shows components, incidents and maintenance windows. Then sign in as a user outside the group and confirm access is denied. Repeat the check from a device outside the corporate network if remote access is expected. Record the results in the change ticket. This step is done when both positive and negative login tests pass and the results are documented.
Restrict who can edit pages
Limit editing rights to a small named group of incident communicators, and remove any shared or default administrator credentials from day-to-day use. Confirm that the editor role is mapped only from the identity provider group and that local accounts are disabled or tightly controlled. Review who can change page visibility, since a mistake there can expose internal incident detail. This step is done when a list of editors matches the access review and an editor test confirms that a viewer cannot change content.
Document and rehearse the rollback
Write a rollback plan that covers reverting the DNS record or proxy route to the previous status page, disabling the identity provider client if access must be closed quickly, and restoring the previous application version from the backup taken before the change. Name the people who can execute each step and where the runbook is stored. Confirm the change window with the operations team and the identity provider owner before publishing the page to employees. This step is done when the runbook has been reviewed, the rollback steps have been rehearsed in a non-production environment, and the page is announced to the audience.

Keeping Keycloak and the status page upgradable

The SSO layer decides whether a self-hosted private status page stays reachable during an incident, so its upkeep matters as much as its setup. Keycloak has shipped four minor releases a year since Keycloak 26.0, and the project says breaking changes in a minor release are opt-in. The current release is 26.8.1, published October 13, 2026. Plan a recurring review of each minor release notes against your realm configuration, client registrations and any custom authenticators before you adopt it. Keep the status page's OIDC or SAML client settings in version control so a redeploy can be checked against a known baseline.

Schema migration runs automatically at startup by default, which is convenient for a small instance but risky for a large one, because a failed migration can leave the identity service down during the window you most need it. Keycloak's upgrading guide suggests manual migration for large deployments, where administrators apply the SQL themselves after reviewing it. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates for the same reason. Decide which mode you will use before go-live, document the rollback path, and take and test a database backup before every upgrade.

For high availability, Keycloak documents a single cluster optionally spread across availability zones and a multi-cluster v2 design without external Infinispan. Both supported designs need a synchronously replicated database, so confirm that your PostgreSQL or other supported database offers this before you size the cluster. The multi-cluster v1 design, which used a separate Infinispan cluster per site, is deprecated and should not be chosen for a new build. Your team owns the upgrade calendar, testing, database backups, certificate renewal and on-call response. A support retainer from DeployOpen would cover scoped work such as planning and executing upgrades, hardening and runbooks, under a written scope. Confirm the split with your own staff before signing.

Evidence that access to internal status pages is controlled

An internal auditor or assessor will ask for proof that only authorized staff can see internal status pages and that edits are traceable. The cards below list the artifacts that usually answer those questions, and they show how OneUptime Enterprise features and your identity provider produce them. DeployOpen prepares this evidence, but independent auditors or certification bodies make the assessment.

Identity provider client inventory

List every OIDC or SAML client that the status page uses, including the client ID, redirect URIs, allowed scopes and the owner who approved it. An assessor will compare this list with your identity provider configuration to confirm that no unregistered application can reach internal pages. If you run Keycloak, export the client definitions from the realm so the inventory comes from the system of record. Confirm with your identity provider team who owns each client.

Proof that SSO is mandatory

Keep the status page configuration that shows the private page requires sign-in, with no anonymous or guest view of internal incidents. Capture the setting as it stands, plus a test from an unauthenticated browser session that is redirected to the identity provider. OneUptime Community Edition supports SAML and OIDC single sign-on, so confirm in your own instance that the private page enforces it rather than only offering it.

User access reviews tied to directory groups

Map status page visibility to directory groups, such as an IT operations group, and run periodic reviews of who belongs to each group. The review record should show the reviewer, the date, the members removed and the approval. Membership changes made in the directory should flow to the status page without manual copies. Ask your identity team which group is the source of truth before the first review.

Automated user provisioning through SCIM

OneUptime Enterprise adds SCIM provisioning, which lets your directory create, update and remove status page users automatically. Assessors usually want to see that joiners, movers and leavers are handled by the same process as other internal systems. Document the provisioning mapping, the attributes synchronized and the sync schedule. Confirm with the vendor that SCIM is included in the edition you license.

Change records for incidents and maintenance

Audit logs should show who created, edited, published or deleted each incident and scheduled maintenance notice, with timestamps. OneUptime Enterprise audit logs cover this activity, so an assessor can trace a published status message to a named account. Export the logs on a set schedule and store them outside the status page server. Confirm the retention period of the log store in your deployment before relying on it as evidence.

Deprovisioning test results

Test that a user removed from the directory loses access to internal pages within the time your policy requires. Record the test account, the removal time, the access attempt and the result. This is the evidence most often missing in assessments, because it shows that revocation works end to end. Repeat the test after each identity provider or status page upgrade, and keep the results with the access review records.

What do buyers ask before moving private status pages behind SSO?

What does moving private status pages behind SSO cost?

The cost is mostly labor and recurring operations, and it depends on how ready your identity provider is and how many audiences you need. You pay for planning, installing and configuring the status page platform, connecting it to your identity provider, setting up each audience and its access rules, and handing over documentation. Ongoing costs include hosting, upgrades, certificates, and notification delivery such as email or SMS. Ask any provider for a written quote that splits one-time work from recurring costs and states which integrations are included. DeployOpen does not publish a price list. A quote follows from the written scope.

What drives the effort when moving status pages behind SSO?

Four factors set most of the effort: identity provider readiness, the number of audiences, the integrations you need, and the hardening your security team expects. An identity provider that already supports OpenID Connect or SAML with clean group claims is far quicker to connect. Each audience (for example, engineering, support or executives) needs its own membership rules and content. Integrations with on-call tools or ticketing systems add testing. Hardening covers TLS, access logs and session settings. Each factor should appear as a line item in the written scope.

How long does a private status page migration take?

The timeline depends on the scope agreed in writing before work starts and on your change windows. Most engagements are fixed-scope, so deliverables and dates are fixed in the statement of work rather than estimated after the fact. Pace is usually set by directory access approvals, DNS and certificate changes, and the time your teams need to test sign-in with each audience. Confirm the expected schedule and any dependencies in the written proposal, and ask how many change windows the plan assumes.

What must our team provide before the work starts?

The work needs four things from your side: access to your directory or identity provider configuration, control of the DNS records for the status page domain, the ability to issue or install TLS certificates, and a named owner who can approve changes and decide on audience membership. Without directory access, group mapping cannot be tested. Without DNS and certificate control, the page cannot run on your domain. A named owner keeps approvals moving between security, IT and communications teams.

Can our own team run a private status page without outside help?

A small team can usually set up a single Uptime Kuma status page behind its identity provider, since the project installs with Docker Compose or one docker run command and supports SSO-fronting at the proxy layer. OneUptime and Keycloak take more effort. OneUptime has Docker Compose and Helm options, plus SAML and OIDC single sign-on in Community Edition, but it covers many more features that need configuration and testing. Keycloak requires a supported production database, a high availability design that uses a synchronously replicated database, and careful upgrade planning. Your team should weigh its staff time against these tasks before deciding.

What recurring costs remain after a self-hosted status page goes live?

Recurring costs include hosting the status page platform, keeping its components and dependencies patched, renewing certificates, monitoring the status page itself, and paying for notification delivery. Email delivery depends on your mail service, and SMS or phone alerts are charged by the provider you choose. Keycloak or another identity provider, if you run one, adds its own upgrade and database costs. Release cadence matters too: Keycloak plans four minor releases a year, and its operator documentation recommends manual approval for updates. Ask your provider for a written upkeep plan that names who performs each task.

Do we need Statuspage pricing confirmed in writing before deciding?

Yes. Statuspage plan terms, including how private and audience-specific pages are priced by authenticated subscriber, can change, so confirm the current figures directly with Atlassian in writing before you compare costs. Ask for the plan that includes your number of subscribers, team members and page types, and the price for each. Use those written figures as the baseline for your own cost comparison, and keep the quote with your renewal records.

Does DeployOpen offer fixed-scope work and ongoing retainers?

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit reports or certifications.

How DeployOpen deploys private status pages under your identity constraints

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For internal status pages, we start from how your identity provider, network boundaries and audience groups work, then build the page so employees sign in through your existing controls.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which internal audiences see which components, incidents and maintenance notices.
We confirm your identity provider, SAML or OIDC requirements, and whether the page needs SCIM or group mapping.

How we build

We deploy either a self-hosted OneUptime private page or an Uptime Kuma status page behind your identity provider.
We configure SSO, map monitored services to internal components, and set notification channels for employee audiences.
Testing covers sign-in, access denial for unauthorized users, and that private pages stay off public DNS and indexes.

How we hand over

You receive documentation of the deployment, identity configuration, network placement and access rules for the page.
Runbooks cover adding or removing audiences, rotating client secrets and publishing an incident update during an outage.
Backup, restore and upgrade procedures are documented so your team can run the page after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer alongside the fixed-scope build.
Upgrades are planned as written changes, so identity and status page configuration are retested after each release.
Confirm with us which parts of the page, such as email or SMS delivery, your team or a third party will operate.