Which monitors should we put on our public status page?

Then your status page should have roughly three entries, not forty. A structure that works: 1. List components in customer language, not infrastructure language. Web application, API, File uploads. Your customer does not know what a queue worker is and cannot act on it being down. 2. Back each customer-facing component with the monitor that best represents it end to end. For the web app that is usually an outside-in check of the page a customer actually loads, not an internal port check. 3. Keep internal monitors off the page entirely. Database ports, queue depths and worker heartbeats belong in your internal alerting. They are how you find out, not what you announce. 4. Be careful with anything that flaps. A component that shows degraded twice a week trains customers to ignore the page. If a monitor is noisy, fix the monitor before you publish it. One more piece of advice from experience: the value of a status page comes mostly from what you write on it during an incident, not from the automatic colour of the dots. Agree in advance who writes the customer-facing update and how often it gets refreshed, otherwise the page goes red and then stays silent, which is worse than having no page.