A status page tells people what is happening when something is wrong. Its value is entirely in being reachable when your main site is not, which is the requirement that decides everything about how you build one.
It must not depend on what it reports on
A status page hosted on the server it describes is a status page that goes down with the outage. So is one on the same account, the same machine, or behind the same proxy.
Host it somewhere genuinely separate: a static page at a different provider, a free hosted status service, or at minimum a different server on different infrastructure.
The same applies to its domain. A status page at status.example.com is unreachable if the outage is DNS for example.com, which is a real and common outage: a separate domain, or a subdomain whose DNS is elsewhere, removes that dependency.
Keep it static
Plain HTML, no database, no application. The point is that it works when other things do not.
A status page built on the same stack as your site inherits the same failure modes, which defeats the purpose in exactly the situation it exists for.
Say four things
What is affected. What is not. What you are doing. When you will next update.
That last one matters most. "Next update in 30 minutes" stops people checking every two minutes and stops them contacting support to ask whether you know, which is most of the load an outage generates.
Then post that update when you said you would, even if the only news is that there is no news. A missed promised update is worse than not having promised one.
Write in plain language
"Degraded performance on a subset of nodes" tells a customer nothing. "Some websites are loading slowly" tells them what they are experiencing.
Say what it means for them: can they reach their site, is mail delivering, will orders be lost? Those are the questions behind the visit.
Avoid detail that is really an excuse. People want to know when it will work, not whose hardware failed.
Automated checks alongside the manual notice
Most hosted status services can display automated checks. A page loading, a service responding: alongside your written updates.
That is useful and it is not sufficient on its own. An automated check says a server answered; it does not say the checkout is broken or that mail is queued.
Use both: the checks give continuous signal, and the written notice gives meaning. For the checks themselves, see How to Set Up and Read Uptime Monitoring.
Post scheduled maintenance too
A status page used only for failures is a page people associate with bad news and never check otherwise.
Announce planned work in advance, with what will be affected and for how long. That builds the habit of looking, so the page is already familiar when it matters. How to Plan and Run Server Maintenance Windows explains the window itself.
Let people subscribe
An outage is when people most want to be told rather than to check.
Email or a feed is enough. What matters is that the notification does not go through infrastructure that is currently broken. A mail server on the affected machine cannot announce its own outage.
Close the incident properly
When it is over, say so plainly and say what happened.
A short note, what failed, how long, what you changed so it does not recur, does more for trust than the uptime figure does. Customers forgive outages and remember silence.
Keep past incidents visible rather than deleting them. A page with a handful of resolved incidents over two years reads as honest; an empty one reads as unused.
For a reseller
Your clients experience your upstream provider's outages as yours, and they will contact you rather than them.
A status page you control lets you say what you know without repeating it in twenty tickets. Link it from your support replies and from your billing area. Reseller Support Workflow in WHM goes into keeping that consistent.
Say what your provider has told you and nothing more. Speculation posted during an incident is what you are held to afterwards.
Put it somewhere the outage cannot reach
A status page on the same infrastructure as the service is unavailable exactly when it is needed.
dig status.example.com A +short dig example.com A +short curl -sI https://status.example.com/ | head -1
Compare the two addresses. If they match, the page shares the server, the network and the provider with the thing it reports on.
The DNS matters as much as the hosting. A status page on a separate host but the same nameservers is unreachable during a DNS failure, which is one of the outages people most want a status page for.
Say what people actually want to know
An update saying that engineers are investigating tells the reader nothing they had not assumed.
Four things are useful: what is affected, what is not, when the next update will come, and whether anything is required of them. The third is the one that stops people asking, since a stated time removes the reason to check repeatedly.
Post the next update when promised, even if the position has not changed. An update saying there is nothing new is more reassuring than silence, and silence is what generates the support volume a status page exists to prevent.
Write the incident up afterwards
The note published after an outage is read by more people than the updates during it, and it is what determines whether the incident damages trust.
State what happened, what the effect was, how long it lasted and what is being changed. Avoid attributing it to a supplier without saying what you are doing about the dependency, since that reads as an excuse rather than an explanation.
Keep the history rather than removing old incidents. A page showing several resolved incidents over two years is more credible than one that is permanently green, because nobody believes the second.