Status pages
A page anyone can load to see whether your service is working — so during an incident your inbox is not the status page.
Nothing is public until you say so
Two switches, both off by default. The page itself must be published, and each monitor must be published individually.
That is deliberate. Publishing is a security decision — a status page lists the hostnames you monitor, which is a map of your infrastructure — so there is no “publish everything” button to click by accident.
A live page with no monitors on it is worse than no page: visitors read a blank page as “fine”. The dashboard warns you if you publish a page and leave it empty.
Your address
The page lives at /status/your-slug. Pick the slug yourself under Status page — it defaults to your organization name, which is rarely what you want customers to see.
What visitors see
Only what you published: the monitor name, whether it is up, and when it was last checked. Never the target URL, the response, or anything about your other monitors.
Status is never colour alone — every state is a coloured dot and a word. Roughly one in twelve men cannot reliably tell the green from the red, and this is the page where that matters most.
The page updates itself while it is open, so someone watching during an incident sees recovery without refreshing.
From the API
# Publish one monitor
curl -X PATCH https://sysops247.io/api/v1/monitors/$ID \
-H "Authorization: Bearer $BEACON_API_KEY" \
-H "Content-Type: application/json" \
-d '{"public": true}'
# The public read model — no credential, this is what your customers get
curl -s https://sysops247.io/api/v1/public/status/your-slugIn a declared file, set "public": true on the monitors you want listed.