Post to your status page when customers can observe a problem or are likely to soon, and you have confirmed it with your own signals. Do not wait for a root cause. Do not post purely internal issues. Write your threshold down so on-call engineers are not deciding it alone at night.
The core rule
Customer impact is the trigger, not internal severity. A database failover that nobody notices is an internal event. A five minute spike of failed API calls is a public one.
A four question test
Ask these in order.
- Is a customer facing component failing or slow, measured by your own monitoring?
- Is it affecting more than a handful of tenants, or a critical group?
- Has it lasted longer than your threshold, for example 10 minutes?
- Are customers already contacting support about it?
Two or more yes answers means post. A yes on question four alone is a strong sign that you are late.
Cases people argue about
Scheduled maintenance. Post ahead of time, with a window and the expected effect.
A vulnerability being patched. The status page is for availability. Publish a security advisory for the vulnerability itself, and use the status page only if patching causes downtime.
Suspected security incident. Do not post speculation. If service is disrupted, post the availability facts. Handle confidentiality questions through a direct customer notice, written with legal review.
Third party outage. If it breaks your customers' workflows, post, and note that an upstream provider is involved.
Degraded performance. Post when latency crosses a number you picked in advance.
Who decides
Name the roles. Typically the on-call engineer can post the first "investigating" message using a template, and an incident lead approves anything beyond availability facts. Remove the fear of posting too early: an early post that turns out to be a blip is cheaper than a late one.
Record the decision
Add one line in the incident record: posted or not posted, and why. In your monthly review, look at incidents with no post and ask whether customers noticed.
Quick check
Is it bad to have many small incidents on the page?
A history of short, honestly handled incidents builds more trust than a spotless page that customers know is not true.
Can automation post for us?
Automation can open an investigating entry from a confirmed monitor, but have a person own the wording after that.
Last reviewed: 19 October 2026.
