Major Incident & Outage Status Board: One Source of Truth When Things Break
When a system or building goes down, your team posts the affected services and live updates in one place, an incident lead approves every message, and staff get notified — so the help desk isn't buried in 50 tickets for one outage.
An internal status board where the team declares a major incident, an incident lead approves the public message and every live update before it posts, affected staff are notified by severity, related tickets auto-link to the one incident, and the whole thing closes out into an incident log with a CSV export.
Before you start
- A Supabase account (free)
- A Vercel account (free)
- A Resend account (free)
- A list of services/systems/locations to status, a staff/subscriber list, and your severity definitions (CSV or Google Sheet)
- Claude Code or any AI coding agent
The problem this kills
One core system goes down — email, the ERP, the building's power, the VPN — and within ten minutes your help desk has forty identical tickets, three frantic Slack threads, and a phone that won't stop ringing. Everyone is asking the same question ("is it just me?") and your one engineer who could actually fix it is instead answering it forty times. Meanwhile nobody outside the room knows what's affected, whether it's being worked on, or when it might be back.
The fix isn't more tickets — it's one place that tells everyone the truth, kept current by the people handling the incident. A status board turns "is it down?" into a link. It collapses fifty tickets into one incident. And because the wrong message during an outage can make things worse, it puts an incident lead's sign-off in front of every word that goes out. You do not need to be a developer to build that. You need this plan and an afternoon or two.
What you'll build
A simple internal web tool for your IT, service-desk, or facilities team. When something breaks, anyone on the team can declare an incident: pick the affected services or locations, set the severity, and draft what staff should see. The incident lead reviews that draft and clicks Approve — and only then does the message appear on the status board and a notification go out to the right staff (severity decides who). As the situation changes, the team posts live updates (also approved), the board shows the timeline, and when it's fixed the lead marks it resolved and adds a short post-incident note. Every incident closes into an incident log you can export as CSV. Internal working notes stay separate from the public message, related tickets auto-link to the one incident, and a dedupe guard stops two people declaring the same outage twice.
What's inside the Implementation Plan
The downloadable plan is a step-by-step file you paste into an AI coding agent. It opens by interviewing you about your business — the services, systems, and locations you'd ever need to status, who's allowed to declare and who's allowed to approve, your real severity levels and what each one means, who gets notified at each level, how you tell two reports of the same outage apart, and how tickets reference an incident today. It reads a short spec back to you for a thumbs-up, then builds the tool around your answers instead of a generic template. From there it walks the agent through the data model, the declare flow, the approval gate, the public board, severity-based notifications, live updates, resolution and post-incident notes, ticket linking, and the CSV export. Every step ends with a ready-to-copy prompt.
The governance it includes (this is the point)
This isn't a toy. The plan builds in the controls a real operations function needs: login so only your team can post, row-level security so each organization only ever sees its own incidents and subscribers, a complete audit trail of every declaration, edit, approval, update, and resolution (who, what, when), a hard human-approval gate so nothing is posted to the board or broadcast to staff until an incident lead signs off, and duplicate guards so one outage becomes one incident instead of three competing ones. Internal notes are kept strictly separate from the approved public message, so the rough draft and the candid working chatter never leak out.
Who it's for
IT and service-desk managers, incident managers, and facilities or internal-comms leads — anyone who is the calm voice when something is on fire and needs one trustworthy place to say what's happening. If you can describe your services, your severity levels, and who signs off on a message, you can build this.
You've got this — open the plan, paste the first prompt, and you'll have your team statusing its first test incident this weekend.