Private Status Pages

Not every status page belongs on the open internet. An internal portal, a platform only a handful of customers use, a service under a confidentiality agreement: the information is meant for a defined group, not for search engines.

For those, you can put a status page behind a password, restrict it to specific networks — or both.

Available on the Business plan. Move to a smaller plan and the password and network restriction stay until you remove them. Removing works on every plan, setting them only on Business.

Setting it up

  1. Status Pages → your page → "Display" tab → Visibility
  2. Enter a password under Password protection (at least 8 characters)
  3. Save

From then on, visitors see a prompt instead of your status page. You hand the password out yourself — we never send it.

Your team is the exception, in the preview only. Signed in with a confirmed address, your team sees the page through Preview in the dashboard without password and without the network check below. On the page's own address the protection applies to everyone, your team included — test it there, or in a private browser window.

Changing it: enter a new password and save. The old one stops working, and everyone already inside has to enter the new one. That is deliberate: a password change that leaves existing sessions open is not a password change.

Removing it: the Remove password protection toggle appears once a password is set. The page is then readable by anyone with the link again.

The field never shows the password you set — we store only its hash and cannot read it back either. If you forget it, set a new one.

What is protected

Everything the page publishes:

  • the status page itself and every incident and maintenance page
  • the history page
  • the RSS feed and the calendar feed
  • the embeddable status badge
  • the status API at /summary.json

Important for badges: a badge on someone else's website has no session, so it will get an error instead of an image. If you use badges, pick one: password protection, or publicly embedded badges. Not both.

What is not protected — and why

The unsubscribe links in emails to your subscribers. Someone who wants out has to be able to get out without a password to hand. Forcing a password on someone before they may stop your emails would be hostile, and legally awkward besides. Verification, unsubscribe and management links therefore always work.

The pages behind those links show that subscriber's own data only, never your incidents.

Restricting to networks

Instead of, or in addition to, the password you can say which networks the page is reachable from at all. The typical case: an internal status page that should only open from the office network and the VPN exit.

Under Visibility → Restrict to networks you list individual addresses or ranges:

203.0.113.4
10.0.0.0/8
2001:db8::/32

IPv4 and IPv6, single addresses and CIDR ranges. An empty field means no restriction.

Anyone coming from elsewhere sees a notice with their own IP address, which they can pass to whoever maintains the list. The same things are covered as with the password: page, incidents, maintenances, history, feeds, badge. Unsubscribe links keep working from anywhere here too.

Both together is an AND, not an OR. With both set, a visitor has to be on an allowed network and know the password. The network check comes first: from outside, the password is never even asked for.

Check your own address before you save. Enter a network you are not on and you lock yourself out of the public page — the dashboard is unaffected, so you can always correct the list.

One limitation worth knowing: what is compared is the address the request arrives from. Put your status page behind your own proxy or CDN and that proxy's address is what arrives, not your visitors'. Tell us if you plan to do that.

Not a substitute for access management

A password everyone shares is a password everyone shares. You cannot tell who opened the page, and when someone leaves the company you have to change it for all of them.

For what a status page is for — "is the service up right now?" — that is usually proportionate. For anything beyond that, the detail belongs somewhere else.

The prompt itself is never indexed by search engines, whatever your other settings say.

Too many attempts

The prompt accepts 10 attempts per minute per IP address. Beyond that it returns an error for a while. That slows automated guessing down without getting in the way of a customer who mistypes twice.

Through the API

Setting, changing and removing all work over the REST API:

# Set or change
curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_password": "at-least-eight-characters"}'

# Remove
curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_password": null}'

The network list likewise:

curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_ip_allowlist": ["203.0.113.4", "10.0.0.0/8"]}'

An empty list lifts the restriction. Invalid entries are rejected with a 422 rather than silently failing to match.

The API never returns the password. The is_password_protected field only tells you whether one is set; access_ip_allowlist comes back in full, since it is not a secret.

A read-only token cannot change the password — see API tokens.