Communication standard
Incidents should explain three things quickly: what broke, what users likely experienced, and what is still being checked. Once recovery is stable, the status surface should explain the trigger and the corrective action in plain language.
Example public entries
What belongs on this page
- user-visible degradation in core surfaces
- planned maintenance that can change expected behavior
- recoveries that require confidence-building follow-up
- system issues that affect trust, not just internal dashboards
What does not belong here
- every tiny background blip that users never felt
- vague “monitoring” posts with no user framing
- technical jargon that hides impact
- silent recoveries on surfaces where users clearly noticed the problem