IT Outage Notification Template

The nine IT outage notification templates below cover what a service desk sends employees from the first notice to the reason-for-outage summary, with [placeholders] for the system, the scope, the workaround and the next update.

The wording is rarely what goes wrong. The notice goes out late, or through the channel that is down.

Then the help desk is swamped by callers reporting the same problem: agents log duplicate tickets against the major-incident record, users who are actually blocked wait behind them, and the bridge is interrupted by the service desk and managers asking for updates.

Scale adds its own failure points: several sites and time zones, shift workers who start after the first notice has gone out, and contractors without a directory account.

These templates cover failures of IT systems. If the building has lost power, use our power outage notification templates instead.

Read more: 16 Common Helpdesk Problems and How to Solve Them

Table of Contents

1. Seven decisions the outage communication plan settles before the incident

2. What an outage communication template should include – the workaround and the next update first

3. Nine system outage notification templates, from the first notice to the reason for outage

4. To notify all employees about a system outage, choose a channel that does not depend on the failed system

5. Outage notification software turns the plan into saved notices, recipient groups and a resend list

6. Frequently asked questions

Seven decisions the outage communication plan settles before the incident

The post-incident review will ask when the first notice went out, to whom and through which channel, and the only defensible answer is the one agreed on before the incident. That agreement is the communication plan: an incident communication runbook gives the plan its structure, and the nine templates below give it its wording. The plan should settle seven things:

• Facts before cause. Say what is confirmed and what it affects. If the outage may have an internal cause, save the cause for the reason-for-outage message, sent once the root cause is confirmed and the wording signed off; accountability belongs in the post-incident review, not in an all-staff notice.
• Honesty about the unknowns. If engineering cannot stand behind a restoration time, say so and give the time of the next update instead; a missed estimate costs more trust than no estimate.
• Symptoms, not components. “You cannot open files on the S: drive” tells employees whether they are affected; “SAN controller fault” does not.
• A first-notice target. Agree on the maximum time between declaring a major incident and sending the first notice (for example, 15 minutes for a priority 1, even with the cause unknown) and the update interval for each priority level.
• Scope rules for the first hour. Early in an IT outage the scope is often unclear: notify too widely and people learn to ignore notices, too narrowly and the calls come anyway. Agree on who sets the scope, and map each critical system to its user groups in advance – application users rarely match directory groups cleanly.
• A channel that survives the failure. For each critical system, note which channels fail with it: a Microsoft 365 outage can take email, Teams and a SharePoint intranet down together; pop-up alerts need the alerting server to be reachable from the computer; and SMS and the recorded message on the help desk line reach the people the other channels miss.
• A named owner. The incident manager runs the fix; someone else – the service desk lead or an incident communications lead, with an after-hours deputy – owns the notices. Security notices usually need a security approver as well, and legal where personal data may be involved. Pre-approve the security template with them, so that during an incident the first notice needs only one sign-off.

What an outage communication template should include – the workaround and the next update first

In an outage or downtime notification, the workaround and the time of the next update do the most to stop repeat calls.

In full, a notice covers:

• The symptom in the user’s terms, and the systems that depend on the failed one – a single sign-on fault can lock users out of every application behind it.
• The scope: company-wide, one site or region, or one group such as remote staff on the VPN.
• Whether to open a ticket: “no need to report this” stops duplicates, and “report it only if you see it outside [scope]” still lets you find the edge of the outage.
• The workaround, or a plain “there is none yet – wait for the next update.”
• An incident reference, so agents can link the contacts they still receive.
• The estimated restoration time, when engineering has one.
• The time of the next update, and a promise to send it even if there is nothing new.

For the first system down message, when there is no time for the full list, keep a five-line checklist in the runbook, where the notice owner can reach it. We call it ALERT:

A    – the affected APPLICATION and the symptom users see

L    – the LOCATION or group affected

E    – the EVENT: planned or unplanned, and since when

R    – the workaround until the RETURN to service, and the time of the next update

T    – whom to TALK to, and whether a ticket is needed at all

Nine system outage notification templates, from the first notice to the reason for outage

All nine are written for employees, not customers. Apart from the network one, each works as a system outage email template, with a subject line, or as the text of a desktop alert. Replace the [placeholders] and cut what does not apply.

Planned Maintenance Notification

For reminders and follow-ups, see our scheduled maintenance message templates.

Unplanned Outage Notification

Network or Internet Outage Notification

Send this one by SMS or mobile push: affected computers may not receive a desktop alert. Keep it within 160 characters and leave out curly quotes and en or em dashes, which can switch a text message to a format that fits only 70 characters; plain hyphens are fine.

Degraded Performance or Service Interruption Notification

Third-Party Service Outage Notification

Security Incident Notification

Extended Outage Notification

Outage Resolved Notification

Reason for Outage Summary

Whichever templates you use, try each once in a quiet week, so the wording and the recipient groups are ready before you need them.

Download all 9 IT outage notification templates

The download puts the nine notices above in one file.

Download free message templates

To notify all employees about a system outage, choose a channel that does not depend on the failed system

Notifying all employees about a system outage takes three things: the channel, the recipients and the follow-up.

Choose the channel. An intranet banner waits for someone to open the intranet, and some help desks turn to the pop-up commands built into Windows instead; our guide explains how to send a pop-up message to all computers on a network that way and what those commands cannot do.

Match the channel to the urgency:

• Urgent: a desktop pop-up alert on the employee’s screen.
• Ongoing status: a scrolling ticker at the top or bottom of the screen.
• Locked or idle computers: lock screen and screensaver messages.
• Away from desks, or the office network is down: SMS, a text-to-call voice message or mobile push.

Target by audience. Send the notice only to the groups or organizational units, synchronized from Active Directory, that use the affected system.

Track and follow up. Whatever sends the notice has to show who has received it and let you resend it to the rest; a distribution list cannot. Our guide to reducing help desk tickets during IT outages covers the help desk side.

Outage notification software turns the plan into saved notices, recipient groups and a resend list

What the nine notices cannot supply on their own has to be in place before the incident is declared, and keeping it ready is what an outage notification system is for – it is what DeskAlerts, our own IT alert software, is built to do.

In the DeskAlerts console, publishers save the nine system outage messages above as drafts, or start from a template, and fill in the placeholders when the incident is declared. If your process requires a second sign-off, switch on the optional approval workflow: each notice then sits in Pending Approval until it is approved by a publisher who holds that role.

Messages go to the whole company or to selected groups, organizational units or IP ranges – for example, only the finance groups when the ERP is down at month-end, or the staff of one site when its file server fails. Where an application’s users do not match a directory group, a group for them can be created in the console beside the synchronized ones. People outside the directory – contractors, agency staff – are not in the synchronized audience. Add them as recipients with a phone number for SMS, or record the gap in the plan rather than discover it during the incident.

What to prepare for each channel:

• Pop-up alerts: one saved as a draft with high priority and acknowledgment required – it stays in front of other windows and closes only when the employee clicks Acknowledge.
• Push notifications and SMS text messages: the SMS gateway tested and the mobile app registered on phones in advance.
• Scrolling desktop tickers (Windows 10/11 and macOS only): a status ticker saved as a draft, then duplicated for each update during a long outage.
• Lock screen messages (Windows only): a notice ready to publish, so an outage declared before the workday can already be on locked screens when people arrive.
• Screensavers (Windows only) and digital signage: a status slide ready to publish, and the signage address already open on the screens in shared areas such as the service desk floor or a cafeteria.

Once a notice is out, the reports show who has received it, who has not and who has acknowledged it. A resend can be limited to the people who have not received it, or not acknowledged it. The Users Action Log records the time a publisher pressed Send, which is the evidence behind the time-to-first-notice figure.

Only desktop alerts record an acknowledgment; on the mobile app, receipt counts from the moment the employee opens the alert. Desktop agents and the mobile app must reach the DeskAlerts server, in the cloud or on premises, and SMS and text-to-call leave through your own third-party gateway (Twilio is the documented one). A VPN or sign-in outage that cuts the path to the server takes the desktop and mobile channels with it; a gateway fault takes SMS and text-to-call.

The seven decisions, the approvers and the quiet-week test stay with the plan. The software holds the result; it does not make the decisions.

The channel list and deployment options are on the IT outage notification software page.

After a major incident, review the notices against the timeline: when the first one went out, how many duplicate contacts arrived before and after it, and which groups say they never saw it. Report two numbers to management – time to first notice and duplicate contacts per incident, each against the last similar incident. That is the evidence for changing the plan.

Evaluating tools to keep employees informed during outages? See how DeskAlerts compares to other notification tools across features, targeting and reporting.

Frequently asked questions