Status Page Best Practices

Short answer. A status page is the public shop window for your service's availability. A good one cuts support load during an incident, builds trust, and gives users an answer before they open a chat. A bad one is updated by hand, always shows "all good," and loses credibility after the first hidden outage. The difference isn't design — it's honesty, timeliness, and automation.

Why you need a status page at all

When a service is down, users don't know what broke: your site, their internet, or something in between. With no information, they flood support, social media, and your competitors. A status page intercepts that flow and provides a single source of truth.

• Cuts support load. One banner — "we know, we're fixing it" — saves dozens of identical tickets.
• Preserves trust. An incident acknowledged on time looks more professional than one that's hidden and then exposed.
• Provides history. 90-day uptime and an incident archive are a sales argument and proof of reliability.

Users forgive outages. They don't forgive silence. A status page that honestly says "we have a problem" builds more trust than one that's always green.

Rule #1: automate instead of updating by hand

A status page updated manually is useless at the exact moment it's needed: during an incident the on-call engineer is fighting the fire, not editing a page. So components must be tied to real monitors.

In enterno.io you flag a monitor as "show on status page," and its state is reflected publicly and automatically. The monitor goes down — the component turns red without your involvement. It recovers — green again. A human steps in only to add a text comment to the incident, while the outage itself is recorded by the system.

Rule #2: components users understand

Break the service into components the way a user sees them, not the way your infrastructure is wired. "API документацию," "Dashboard," "Email delivery," "Payments" — clear. "Kubernetes worker-node-7" — not.

Bad component	Good component	Why
db-replica-eu-2	Authentication	The user doesn't know your DB schema
nginx-ingress	Website	Describes a function, not a technology
queue-worker	Notifications	Makes it clear what's actually affected

Rule #3: honest degradation levels

Availability isn't binary. Between "everything works" and "everything's down" there are intermediate states, and users need to tell them apart:

• Operational — all normal.
• Degraded performance — works, but slowly or partially.
• Partial outage — some features are unavailable.
• Major outage — the component is fully down.

"Degraded" is the most underrated status. If the API responds, but in 5 seconds instead of 200 ms, it's technically "up" yet broken for the user. An honest "degraded" beats a green that lies.

Rule #4: let people subscribe

Not everyone will keep your status page open all the time. Subscriptions solve this: a user leaves an email and gets notified when you open or close an incident. That turns a passive page into an active communication channel and, again, takes pressure off support.

Rule #5: embed status where it'll be seen

A status page on a separate subdomain is good, but an embedded badge in your app's header or your docs works even better: the user sees a green indicator without leaving the page. enterno.io serves badges as SVG compatible with shields.io.

The simplest option is to drop in the badge image directly:

<a href="https://enterno.io/status/your-slug">
  <img
    src="https://enterno.io/api/badge.php?monitor=123&type=status"
    alt="Service status">
</a>

The badge refreshes itself and links to the full status page on click. Available types: status, uptime, response time, days until SSL expiry. The ?powered=1 parameter adds an unobtrusive "Powered by enterno.io" footer.

Rule #6: custom domain and branding

A status page at an address like status.yourdomain.com reads as part of the product, not a third-party service. enterno.io supports public status pages with a custom domain and embeddable badges, so the user stays inside your brand.

What to avoid

• An "evergreen" page. If there hasn't been a single incident all year, users will assume the page simply doesn't work.
• Tech jargon in the incident description. Write for a human: what's broken and what you're doing about it.
• No postmortem. After a major outage, a short root-cause note restores trust. How to build one — in the incident response plan.
• A status page on the same infrastructure as the service. If it goes down with the product, it's worthless.

FAQ

Where should the status page live?

Ideally on infrastructure independent of your main service. If the status page goes down with the product, it's useless at the exact moment of an incident. Hosting it with an external monitoring provider solves this by definition.

Do I need to show every minor glitch?

Show what the user will notice. Restarting one worker that nobody felt is noise. Degradation affecting real people is a must. The yardstick: if it could generate a ticket, it belongs on the page.

How often should I update status during an incident?

Better regular than detailed. A short "still working on it" every 30 minutes is worth more than silence with the promise of one big final post. Users read silence as "we've been abandoned."

Can I embed the badge in a GitHub README?

Yes. The SVG badge is a plain image; it drops into markdown exactly like a build or coverage badge. That's handy for open-source projects and public APIs.

Are status pages available on the free plan?

Public status pages are available for your monitors. On the enterno.io free plan you get 10 monitors and can surface them on a status page; custom domain and advanced branding options come with the paid plans.

Build a status page in five minutes

Open the Monitors section, flag the monitors you want as "show on status page," and set up a public address. Then add subscriptions, embed the badge in your app header, and connect a custom domain.

To make the status page work in concert with the rest of your monitoring, see the website monitoring guide, the uptime monitoring guide, and alerting best practices — the status page is the public face of the data they collect.