How to publish a status page your customers can actually read

A status page is the public sentence of your monitoring: customers should be able to tell, without emailing you, whether you already know. The page is only as honest as the checks behind it. A bar that stays green because you measured from one lucky city is a different product from a bar that uses the same confirmation as your alerts.

Create the page, then decide what it shows

You give it a title and a slug. The slug is lowercase letters, numbers and hyphens, 3 to 40 characters, and the page is served at /status/ followed by that slug. You choose which monitors appear. A page with no monitors is a title. Free includes one status page, Solo three, Team one hundred, Enterprise as many as you need.

• History window: 7 days, 30 days, 90 days or 1 year. The uptime bars use the same cross-region confirmation as incidents, so a single slow region does not paint downtime next to a page that lists no incident.
• Theme: follow the visitor’s system, or force light, or force dark.
• Language: the page is rendered in the organization’s language, English or German. It does not switch per visitor.
• Logo: upload a PNG, JPEG, WebP, GIF or SVG, up to 512 KB, or paste an image URL. Automatic sizing is 52 pixels tall. A fixed width from 50 to 400 pixels keeps the image’s proportions instead of squashing a wide logo into a square.

The page lists the five most recent past incidents and offers the rest of the history window behind “show more”. Hiding the “Powered by HyperMonitors” footer is a paid-plan switch. An optional password keeps a page off the public internet without unpublishing it.

Two different incident texts

A check opens a monitor incident at “investigating” and resolves it when the target recovers. You move it to “identified” or “monitoring”, post an update, and write what fixed it. Posting an update acknowledges the incident, so repeat alerts stop. The note is stored with the incident and included in the CSV export. That text is for you.

On the public page that detail is hidden by default. The switch is “Hide incident error messages”, and it starts on. While it is on, visitors do not see the automatic cause, your resolution note, or those update texts — they can contain probe errors and hostnames. The state itself is still shown. Turn the switch off only when you want that text public, and open the page in a private window before you announce it.

You can also post an incident on the status page itself: a title, an impact, and updates you wrote for customers. That text is on the page. Confirmed subscribers are emailed when you post one or add an update. They are not emailed merely because a monitor changed state. If you want customers to hear about an outage, you post it.

Subscribers, a custom domain, a badge

• Email subscribers confirm by clicking a link, and they can unsubscribe in one click. The free plan has none. Solo allows 250 confirmed subscribers per page, Team 1,000, Enterprise no fixed cap.
• A custom domain is a CNAME, not an A record, and not at the zone apex. The form prints the target, which is the app host. On Cloudflare, leave the record unproxied. Save, and verification runs on its own; once the domain is live it serves the page over HTTPS. If the form lists a further step on the host, do that too — a CNAME by itself is not always enough.
• Each monitor has a status badge and an uptime badge. The form copies a Markdown image. The URLs are https://api.hypermonitors.com/v1/public/badge/{slug}/{monitorId}?variant=status and the same path with variant=uptime.