Private pages

A status page you hand out, rather than publish.

Not every service you run is a service your customers should be reading about. A private page gives your own team, your QA group or a single customer the same live view — the same monitors, incidents, maintenance windows and uptime history — without putting it on the open web.

Read the next section before you rely on this: private here means unlisted. The page returns a 404 to anyone without the link, and there is no password and no sign-in.

What it is good for

Four jobs it does well.

Private pages are on every plan, including Free, and they count against the same page allowance as public ones.

Internal services

The queue workers, the internal admin tool, the reporting job — things your own team needs a shared view of and your customers have no reason to see.

Staging and pre-production

Give QA and support a page for the staging stack that looks exactly like the production one, without a second product to learn or a second bill.

Before you launch

Set the page up properly — domain, logo, monitors, thresholds — and leave it unlisted until launch day. Making it public is one switch.

One customer, one page

Send a single enterprise customer a page scoped to the services they actually depend on, without publishing it to everyone else.

Read this part

What private does not mean.

This is the single most over-sold word in the status page category, so here is exactly what the switch does and does not do.

The limitation, stated plainly

A private page has no access control. The URL is the only secret. Anyone who has the link — a former employee, a forwarded email, a browser history on a shared laptop, a link pasted into the wrong channel — can open the page and read everything on it.

There is no password on the page.
There is no sign-in, no SSO and no SAML.
There is no allowlist of email addresses or IP ranges.
There is no expiring or revocable share link — changing who can see it means changing the URL.

If your requirement is that only authenticated staff can see a page, StatusOwl does not meet it today. We would rather you found that out on this page than three weeks into a rollout.

Not shipped yet — Up next

Put a shared password or SSO in front of an internal status page, instead of relying on the URL being unlisted. Until it ships, the link is the only thing standing between a private page and whoever has it. See the full roadmap.

What to do in the meantime
  • Treat a private page as unlisted-but-public. Assume the link will eventually escape, because links do.
  • Name services in a way that gives nothing away. "Billing worker" is fine; a page that leaks your internal hostnames and vendor list is not.
  • Keep incident updates factual and free of credentials, customer names and internal ticket links.
  • Use a long, non-obvious page slug. It is obscurity rather than security, but it raises the cost of guessing.
How it works

One switch, and the page stops existing.

There is no half-state and no grace period. A page is either served or it is a 404.

The switch

Each page carries Public, Active and Default switches in the dashboard. They save the moment you flip them — there is no separate publish step and no cache to wait out.

The 404

With Public off, a request for the page gets the same not-found response as a page that never existed. The incident and maintenance detail pages under it 404 as well, and so does the public JSON endpoint.

Search engines

Because the response is a 404 rather than a redirect or a login screen, there is nothing for a crawler to index and no snippet to leak. Nothing about the page reaches search results.

Everything else is identical

A private page still gets a custom domain with automatic SSL, automatic incidents, maintenance windows, ninety days of uptime bars, your logo and the visitor theme toggle. It is a normal page with one thing switched off.

Side by side

Public against private, row by row.

The bottom three rows are the ones people assume are different. They are not.

BehaviourPublic pagePrivate page
Who can open itAnyoneAnyone with the link
If someone has the URLPage loadsPage loads
If someone does notPage loads404 — not found
Appears in search resultsYesNo
Custom domain with SSLYesYes
Automatic incidentsYesYes
Sign-in requiredNoNo
Shared passwordNoNo
SSO / SAML gateNoNo

Access to the dashboard is a different question and is properly controlled: every read and write is scoped to your organisation and checked against your membership and role first. It is the published page, not the account, that has no gate.

Set the page up first. Publish it when you are ready.

Start private, get the domain, logo and monitors right, then flip one switch. Free forever on one page.