Private status pages. Only for those it concerns.
Not every status belongs on the open internet. Share a page only with signed-in clients, only through SSO, with a password or only from certain networks, and show every group only the services that affect it.
Made and Hosted in the
European Union
GDPR-Compliant Hosting
in Germany
GEO-Redundant Replica
across the EU
Public, signed in or SSO. You decide per page.
The page for your client's end customers can be seen by anyone. The page with the internal ERP, the interfaces and staging cannot. For each status page you set who gets in: everyone, only signed-in client members, only accounts through your identity provider, or anyone with the password.
- Client members only, so an internal page is seen only by people who already have access to the client.
- SSO only, so access and removal run through the same identity provider as everything else.
- Password protection for quick sharing, so externals without an account of their own can follow along.
`visibility` is `public`, `customer_members_only`, `sso_members_only` or `password_protected`. With `customer_members_only`, visitors need an account with access to the client, and without a client any member of the organization will do. Without a session visitors get `401`, without access to the client `404`, so the address reveals nothing. `sso_members_only` additionally requires a session through the organization's SSO, otherwise `401 ssoRequired`, and requires verified SSO (`400 ssoNotConfigured`).
Independently, `isPublished` controls whether the page is reachable at all. Unpublished pages show signed-in members with the admin, editor or readonly role a preview with a banner, everyone else gets `404`.
Only from the company network. Invisible to everyone else.
Some clients want no extra login, but no public page either. With an IP allowlist, the page is reachable only from their office network or VPN. The rule applies on top of any visibility, even to an otherwise public page.
- Up to 50 addresses or networks as IPv4 or IPv6, so offices, VPN and data center are allowed together.
- Combinable with any visibility, so an SSO page can also be limited to the company network.
- No caching, so a protected page never sits in someone else's cache.
`ipAllowlist` takes up to 50 IPv4 or IPv6 addresses or CIDR ranges and stores them as `addr/prefix`. `[]` lifts the restriction. The check uses the address our reverse proxy sees, not `X-Forwarded-For`, so a forged header does not help. Blocked visitors get `403 statusPageIpNotAllowed`, and that also applies to the password check.
Responses for pages with an IP allowlist, with audience groups and for previews carry `Cache-Control: private, no-store`.
One page. Every group sees its part.
Your client has three sites, two partner companies and an internal IT team. Instead of maintaining five pages, you create audience groups: each gets its email domain and its components. Whoever signs in sees only what concerns their group, and the overall status is calculated from that alone.
- Up to 20 audience groups per page, so sites, partners and internal teams fit on one page.
- Assignment by email domain, so nobody has to maintain groups by hand.
- Overall status from the group's point of view, so an outage at another site never shows as your own disruption.
`audienceGroups` takes up to 20 groups, each with `name` (1 to 80 characters), `emailDomains` (1 to 20, exact match without subdomains) and `componentIds` (1 to 100). Visitors need to sign in with a verified email address on one of the domains. Components in no group stay visible to everyone who may view the page. Admins and editors see everything.
Components of other groups are left out, as are incidents and maintenance that only affect those components. `overallStatus` and `overallState` are calculated from what the visitor sees. A PATCH replaces all groups, `[]` removes them.
Private means private. For badges and feeds too.
A private page whose status leaks through a badge or a subscription email is not private. That is why pages with login, SSO, IP allowlist or audience groups have no badge, no widget and no feed, and subscriptions are not accepted. The overview shows at a glance how each page is visible.
- No badge, widget or feed on private pages, so nothing bypasses access control.
- No subscriptions on private pages, so no email carries content to people who may not see the page.
- Visibility in the overview, so with many clients you see at once which page is public and which is not.
Badge (`/status/:slug/badge.svg`), widget (`/status/:slug/embed`), RSS and Atom feeds and subscriptions exist only with `visibility: public` and without `ipAllowlist` or `audienceGroups`. All other pages answer `404` there. The subscribe endpoint also answers `{ "ok": true }` for private pages and stores nothing, so it never reveals that the page exists.
We don't just monitor. We help you sell.
Every Uptimeify subscription includes access to our Success Kit, a collection of battle-tested resources to turn your monitoring into a profit center.
Service Level Agreement templates to define professional boundaries with your clients.
Find the sweet spot for your care plans. Calculate margins based on check frequency and support hours.
Powerpoint Templates that explain 24/7 monitoring to non-technical clients. Close more retainers.
Use automated reports to proactively communicate value, so clients never ask what they're paying for.
Ready to turn monitoring into a profit center?
Claim your Success Kit and start scaling today.
Frequently Asked Questions
A status page that not everyone on the internet can see. In Uptimeify it is visible only to signed-in client members, only through SSO, only with a password, only from certain networks or only to certain groups. Typical cases are internal systems, partner portals and services whose disruptions should not become public.
Yes. A shared password is the fastest way to share a page with a small circle, such as a contractor without an account of their own. For lasting access by large groups, sign-in through client accounts or SSO is the cleaner option, because you can then revoke access centrally.
You set the visibility to "SSO only". Visitors then sign in through your organization's identity provider, such as Microsoft Entra ID, Google Workspace, Okta or Keycloak. Whoever leaves the company loses access to the status page along with their account. SSO has to be set up and verified first.
Yes, with audience groups. Each group gets one or more email domains and the components it may see. Whoever signs in sees only their group's components and the incidents that go with them. The overall status is calculated from those components alone.
No, on purpose. Subscriptions, badge, widget and feeds exist only for public pages. Otherwise an email or a badge would carry content to people who may not see the page. For private pages, you inform through the page itself or your team's own channels.
For the technical stakeholder
Ready to show the status only to those it concerns?
Create an internal page for your team, a protected one for your client and a public one for their end customers, all from one dashboard. Each shows exactly what it should.