IT Outage Communication: Templates for Every Stage

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.

Template 5: planned maintenance notice

A planned outage is easier than a surprise, so send the notice early, once at least a week ahead and again a day before.

🔧 Planned maintenance: email unavailable Saturday 18 Jan, 22:00 to 23:30

What's happening: We're moving the mail gateway to a new server. Who is affected: Everyone. Sending and receiving email will pause; messages sent during the window will be delivered afterwards, nothing is lost. What to do: Plan around the window and use chat for urgent messages. Nothing to install or change. If it overruns: We'll post an update here by 23:15 and again every 30 minutes. Questions: Reply to request RLY-840.

State the start and end times with the time zone, say whether anything can be lost, and name the window as a maximum. If the work finishes early, say so.

Some channels have room for one line. Keep the same four facts (what, who, what to do, when next):

Email is down for everyone since 09:10. Chat and files work. No need to file a request. Next update 09:45.

For an on-screen banner or an SMS to leadership, that is the whole message; link to the request or status page for detail.

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.

How do you announce planned maintenance or downtime?

Send the notice at least a week ahead and again the day before, with the start and end time (and time zone), who is affected, whether any data or messages can be lost, what people should do, and where updates will appear if the work overruns. Template 5 above is a ready-to-use example. Say so as soon as it finishes early.

What should an outage report include?

The impact (who was affected, for how long), a timeline, the cause stated as a process rather than a person, what worked and what did not in the response, and specific changes with an owner and a date each. Keep it blameless and short; Template 4 above is the minimal version, and a longer incident report can add the detailed timeline and the monitoring that would have caught it earlier.