Managing the status page

Managing the status page

The status page (visible to end users at /status) shows the health of every system the trust runs. It’s the first thing experienced staff check when something feels off.

The admin side is in Platform admin → Status. Three subsections:

Services

The catalogue of things to show status for. Per service:

• Name — “Email”, “SIMS”, “Wifi”, “Single sign-on”, “Print server”
• Description — what’s behind the name; helps non-technical users
• Group — for the page layout (Identity / Communications / Curriculum / Infrastructure)
• Order — display order
• Default status — Operational (almost always)
• Component link — optional; which other thing on the status page this service depends on (e.g. SIMS depends on the SIMS server)

Each service has a current status; the public page shows them all.

Notices

Banners that appear at the top of the status page (and in-app for logged-in users). Use for:

• Pre-announced maintenance windows
• “Snow day — IT support reduced today”
• Major OS rollouts that affect support availability

A notice has:

• Title + body — markdown-rich
• Severity — Info / Warning / Alert
• Audience — All / Logged-in / Admins
• Visible from / until — auto-hides

Notices are non-incidents. They don’t affect any service’s RAG colour.

Incidents

The big one. When something is actively broken, raise an incident:

1. Create incident — pick the affected services, set the status (Investigating / Identified / Monitoring / Resolved)
2. Initial update — short, public-facing description of what’s happening + what we’re doing
3. Subscribers notified — anyone who subscribed to the affected services gets an email
4. Update as you go — every significant change (new info, escalation, vendor engagement) is a new update post; incident gets a fresh email
5. Resolve — mark Resolved, post a final summary, write a brief postmortem (visible 24h later)

Incident severity

• Major — most users affected; significant business impact
• Minor — some users / functions affected
• Maintenance — planned, expected outage

Severity drives notification urgency and dashboard prominence.

Tone of incident updates

The status page is read by stressed users. Updates should:

• Lead with what’s working — “Email sending is back; receiving still affected”
• Avoid blame — “vendor is investigating” not “vendor screwed up”
• Give an ETA only if confident — “by end of day” is fine; “in 30 minutes” better not be wrong
• Avoid jargon — non-IT readers shouldn’t need a glossary

A well-written incident update earns the trust that lets you push through the hour you’ll need to actually fix the thing.

Postmortem

After resolution, the platform prompts for a postmortem (auto-shown 24h later). Five sections:

1. What happened?
2. What did we do?
3. Why did it happen? (root cause)
4. What are we changing to prevent recurrence?
5. Anything users should know going forward?

Postmortems are public unless the incident involved data sensitive enough to redact. Publishing them is part of how the trust earns trust.