Fictional example · verify your own facts
Degraded performance status update example
See a fictional degraded-performance status update and customer email that describe a slow-but-available workflow without inventing a cause.
Verified facts for this fictional scenario
Affected workflow
Dashboard loading
Affected scope
US workspaces
Current state
Dashboards are loading more slowly than normal; requests still complete
Unaffected workflow
API requests continue to process normally
First observed
09:10 UTC
Current update
09:25 UTC
Cause
Not yet confirmed
Next update promised
09:45 UTC
Customer-ready messages
Why these drafts stay bounded
Degradation is not an outage
The drafts say that dashboard requests still complete instead of describing the workflow as unavailable.
Impact and scope stay concrete
The slower dashboard workflow, US workspace scope, and normally processing API requests stay separate without a customer count, performance percentage, or severity label.
Unknown stays unknown
The cause is not yet confirmed, so neither channel adds a theory, remediation detail, or restoration estimate.
Cadence stays bounded
Both drafts promise the next communication at 09:45 UTC without turning that promise into an expected recovery time.
Draft from your verified facts.
The free acknowledgment and resolution composer runs entirely in your browser.
Open the composer →