The instinct when building a status page is to expose everything you monitor. That instinct produces a page nobody can read and nobody trusts. A status page is a customer communication product. Design it as one.
List components, not infrastructure
Your customers do not know what your queue workers are. They know whether they can log in, whether the API is responding, and whether their uploads work. A good component list is short and written in their language: Web application, API, File uploads, Email delivery. Four to eight components covers almost every product.
Back each component with a check that reflects the customer experience
A component should turn red when a customer would notice, not when an internal metric wobbles. That usually means an outside-in check on something a customer actually does. Keep internal monitoring off the page entirely.
Anything that flaps must not be on the page
A component that goes yellow twice a week teaches customers to ignore the page. Once that happens, the page cannot do its job during a real outage.
The words matter more than the colours
A useful update has four elements: what is affected in their terms, what you know honestly, what you are doing, and when you will update next. That last field most reduces inbound support volume and is the one most often omitted.
Post earlier than feels comfortable
Post as soon as you have confirmed something is genuinely wrong, even if the update is only "we are aware and investigating." That single sentence converts a customer's experience from "this product is broken and nobody cares" to "they know, they are on it."
Keep the promised cadence
If you say the next update is at 14:50, publish something at 14:50. A missed promised update reads as abandonment. Assign this explicitly: the person fixing the problem should not be the person writing updates.
Close the loop
When it is over, post a resolution note, and for anything significant publish a short retrospective within a few days. Companies that publish honest retrospectives get more benefit of the doubt during the next incident.
What not to do
Do not hide incidents. Do not use vague euphemisms. Do not make the page hard to find. Do not host it on the same infrastructure as your product.