These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Status Page System
- Implementation
How a Status Page System rollout works
Prepare service ownership, status language and a rehearsed incident cycle.
Map services
Agree on service names, criticality and owners. Identify the components customers should recognize.
Set access
Link People to Users and test the intended work of each role before using production incidents.
Load context
Add representative assets and current service references. Review change and request status meanings with their owners.
Connect communication
Choose the public destination, monitoring source and subscriber channel. Check the audience and review handoff.
Rehearse a case
Open an incident, acknowledge it, record an update, review public wording, record publication and close after recovery.
What the customer provides
Provide the service list, operating owners, component names, priority conventions, current asset identifiers and the people who make change and communication decisions. Choose an incident whose customer effect can be simulated safely. The team should also identify the external status destination and notification channel it will use.
Changing it afterwards
When a service or component name changes, check existing incidents and planned changes that reference it. Review who owns each service after a team change. Rehearse any revised approval or communication path before relying on it during an interruption. Compare component condition with the incident record during each operational review.
Set up Status Page System your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.