IT Outage Communication: Templates for Every Stage
Clear outage messages cut duplicate tickets and frustration. Copy-ready templates for the first notice, updates, resolution and the follow-up review — plus who sends them, where, and how often.
A good IT outage communication template has four stages: a first notice within minutes (what's affected, who, what to do meanwhile, when the next update comes), regular updates at the promised interval even when nothing has changed, a resolution notice (what's fixed, what people should do now) and a short follow-up with the cause and what will change. One named person sends them, through one channel people already watch, and every update says when the next one will come. That alone prevents most "is it down?" tickets.
Why communication matters as much as the fix
During an outage, the people fixing it need focus, and everyone else needs to know what's happening. Without communication:
- Dozens of people file the same request, flooding the queue.
- Others message engineers directly, interrupting the fix.
- People make up workarounds, some of them risky.
- Trust drops, regardless of how quickly service is restored.
Atlassian's incident communication guidance and most incident-management practice put a dedicated communicator alongside the people fixing the problem for this reason.
Who communicates
Assign roles at the start of a major incident:
- Incident owner — coordinates the fix and decides.
- Communications lead — writes and sends updates; the single voice to the organization.
- Responders — fix the problem, in a dedicated space away from the noise. See team rooms.
In a small team one person may hold two roles; the communications role still matters.
Where to communicate
Pick one primary channel people already watch — the company-wide chat channel or an intranet status banner — and keep it consistent. Supplement:
- Email for people who may not be on chat (or if chat is what's down).
- A pinned request in the help desk that others can follow; link duplicates to it.
- A status page, if you have one, for systems many people depend on.
Always have a fallback channel for when the outage takes out your primary one (a phone tree or SMS list for the leadership group, at minimum).
Template 1: first notice
Send within 10–15 minutes of confirming an incident, even with little information.
🔴 Email is down for everyone — we're working on it
What's affected: Sending and receiving email in Outlook and on phones. Chat and files are working. Since: 09:10. What to do now: Use chat for urgent messages. You don't need to file a request — we know. Next update: 09:45, or sooner if it's fixed.
— Sam (IT), for updates follow request RLY-812.
Why it works: the subject says what and that it's being handled; it tells people what still works; it tells them not to file duplicate requests; and it commits to a next update time.
Template 2: update
Send at the promised time — even if nothing has changed. Silence reads as "they forgot".
🟠 Email still down — cause found, fix in progress
Status: We've found the cause (an expired certificate on the mail gateway) and are replacing it. Expected: Email back by about 10:30. We'll confirm. Still true: Chat and files work. No need to file requests. Next update: 10:15.
Keep updates short. Replace what changed; repeat what's still true. Use times, not "soon".
Template 3: resolved
🟢 Email is working again
Fixed at: 10:22. What to do: Emails sent during the outage will arrive over the next 30 minutes. If something still isn't working after 11:00, reply to request RLY-812. What happened: An expired security certificate on the mail gateway. We'll share a short review tomorrow.
Thanks for your patience.
Say what people need to do (usually nothing, or "restart the app"), and give a clear path if they still have problems.
Template 4: follow-up review
Within a few days, a short, blameless summary:
Review: email outage on 12 November
Impact: Email unavailable for 72 minutes (09:10–10:22) for all staff. Cause: The mail gateway's certificate expired; renewal reminders went to a former employee's mailbox. What we're changing:
- Certificate expiry alerts go to the IT team address, not a person (done).
- All certificates are listed with owners and expiry dates (by 30 Nov).
- A check 30 days before any expiry (by 30 Nov).
Name the changes and their dates. "Human error" isn't a cause; the process that allowed it is. The review often becomes a problem record — see incident vs service request.
How often to update
| Severity | First notice | Update interval |
|---|---|---|
| Everyone blocked | Within 10–15 min | Every 30 min |
| A team or key system affected | Within 30 min | Every 60 min |
| Degraded but usable | Within 1 hour | At meaningful changes, at least every 2 hours |
Adjust to your organization, but always state the next update time and keep to it.
Briefing leadership
Senior leaders need a different message from everyone else: less about what to do, more about impact and decisions. A short direct note, sent alongside the first public notice:
Email outage — 09:10, all staff affected. Business impact: No external email; client meetings via calendar invites still work. Sales team informing key clients by phone. Decision needed: None yet. If not fixed by 11:00, we'll recommend posting a notice on the website. Next update: 09:45.
State the business impact in their terms, flag any decision you may need from them and by when, and keep them on the same update rhythm. Leaders who hear about an outage from a client before hearing it from IT stop trusting the status process.
Handling the flood of tickets
Even with good communication, some duplicate requests arrive:
- Link them to the main incident instead of working each separately; resolving the parent notifies everyone.
- Auto-reply with the status link for requests that match the incident's category during the outage window.
- Don't close duplicates silently — people should see they were heard.
The escalation side — who gets pulled in and when — is in the help desk escalation matrix.
Mistakes to avoid
- Waiting for full information before the first notice. Early and partial beats late and complete.
- Jargon. "DNS propagation issue on the edge" means nothing to most readers; "some websites won't load" does.
- Promising times you can't keep. Give an estimate only when you have one; otherwise commit to the next update time.
- Missing the promised update. It costs more trust than the outage.
- Blame in the review. People stop reporting problems early when mistakes are punished.
FAQ
What should an IT outage notification include?
What's affected and since when, what still works, what people should do meanwhile, that they don't need to file requests, and when the next update will be sent.
How often should outage updates be sent?
At a promised interval — about every 30 minutes when everyone is blocked, less often for smaller impact — and always at the time you said, even if nothing changed.
Who should send outage communications?
A single communications lead, separate from the people fixing the problem where possible, so updates are consistent and responders can focus.
What goes in a post-incident review?
The impact, the timeline, the cause (a process, not a person), and specific changes with owners and dates.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
On-Call Rotation for a Small IT Team: A Fair, Sustainable Setup
How a small IT team can cover urgent issues out of hours without burning out — what's worth being paged for, rotation length, handovers, runbooks, compensation, and reviewing every page.
IT Asset Management for Small Companies: A Lightweight Approach
A practical IT asset management setup for small companies — what to track, one record per asset, lifecycle states from purchase to disposal, linking assets to people and requests, and the security reasons it matters.
Help Desk Escalation Matrix: A Template and How to Use It
An escalation matrix says who gets pulled in, when, and how — by priority and time. A template for internal help desks, functional vs hierarchical escalation, triggers that aren't just time, and how to keep escalation from becoming noise.