ADAM PULSE Network Outage Communication Templates: Initial Notification, Incident Update, Restoration Notice & RCA Summary
Short answer
During an incident, stakeholders need four messages, not a running commentary. The first says what is affected and when you will write again. The updates keep that promise. The restoration notice says the service is working from the user's path. The RCA summary says what the evidence supports after the noise has stopped.
NIST's incident-response guidance treats communication as part of the response, not a courtesy after it. AWS Well-Architected makes the same operational point from the other direction: an alert without a defined response is a notification, not a process. These templates are the customer-facing half of that process. They assume you already have one incident, not eleven alerts — see event correlation.
Replace every bracket. If you do not know a value, write “not yet confirmed” rather than inventing one. Times are written HH:MM ET (HH:MM LOCAL) with the zone visible. Store UTC on the ticket.
Cadence
| Message | When | Job |
|---|---|---|
| Initial notification | As soon as you can name the site, the impact and a next-update time | Stop the rumour. Set the clock. |
| Incident update | On the interval you promised, even if nothing changed; immediately if impact or ownership changes | Keep the promise. Change only the facts that changed. |
| Restoration notice | When users can work on the restored path, confirmed from more than one signal | Close the operational loop. Leave residual risk explicit. |
| RCA summary | After the evidence is assembled — hours to a few business days, not during the outage | Record cause at the level of evidence you have, and the next action. |
A workable default for a customer-facing site outage is an update every 30 minutes. That is a promise, not a law. If you said 30 minutes, write at 30 minutes. “No change; next update 14:10 ET” is a complete message. Silence after a promised time is how people start calling the CEO.
Do not send an extra email every time a dependent alarm clears. That is the correlation problem leaking into the inbox.
What not to say
| Do not write | Write instead |
|---|---|
| “The carrier is down” before isolation | “Primary WAN is unreachable from the monitoring path. Carrier ticket [ID] is open. Cause is not yet confirmed.” |
| “Fully resolved” while production is on the backup circuit | “Users are working on the backup path. Primary remains down. We are still with the carrier.” |
| An ETA you do not have | “No restoration time from the carrier yet. Next update at [TIME].” |
| Internal IPs, SNMP community strings, portal passwords, other customers' site names | Site code, circuit nickname the customer already uses, ticket IDs. |
| A paste of traceroute, MTR or a raw alert dump | One sentence about what the path test showed, with a redacted chart if they asked for evidence. |
| “Human error” or a named technician | “A configuration change at [TIME] is in the window and is being reviewed.” |
| “This will never happen again” | The corrective action, the owner and the date you will check it. |
If two people write the customer, they will disagree about whether the backup is “fine” or “degraded.” Name an owner on the first message. Everyone else feeds that owner.
Linking monitoring evidence without oversharing
Customers and account teams are entitled to evidence. They are not entitled to your other customers, your management plane, or a dashboard that still has yesterday's Sev-1 for a different company in the sidebar.
- Share the window and the conclusion — start, end, site, what failed, what stayed up.
- Share a redacted chart if it supports that sentence: one circuit, one window, axes labelled, management IPs cropped or replaced with labels (
Carrier GW,Firewall WAN). - Share ticket IDs — yours and the carrier's. Those are how later SLA claims stay attached to the incident. See filing an ISP SLA credit claim.
- Do not share a live dashboard URL, a multi-site screenshot, SNMP strings, full traceroute with RFC1918 hops, attachment dumps from the desk ticket, or another client's name in a filename.
- Do not put the evidence in the first notification unless asked. The first job is impact and cadence. The chart belongs on an update or in the RCA.
Template 1 — Initial notification
Send this once. If you learn the first sentence was wrong, the next message is an update, not a second “initial.”
[CUSTOMER] / [SITE CODE] — service impact since [START HH:MM ET] — next update [NEXT HH:MM ET]
To: [STAKEHOLDER LIST]
From: [NAMED OWNER]
Importance: High
We are investigating a service impact at [SITE NAME / SITE CODE].
Started: [HH:MM ET (HH:MM LOCAL)] on [DATE]
Current status: [unreachable / degraded / failed over to backup / unknown]
What users are seeing: [one sentence: voice, VPN, cloud apps, POS, or “not yet confirmed”]
What still works: [LAN / backup WAN / voice / “not yet confirmed”]
What we know: [one factual sentence. No carrier verdict unless isolation supports it.]
What we are doing: [tests in progress / carrier ticket [ID] / waiting on [WHO]]
Owner: [NAME, ROLE, PHONE OR DESK PATH]
Next update: [HH:MM ET], or sooner if status changes.
We will not wait for root cause to write again.
Template 2 — Incident update
Reuse the subject so the thread stays one incident. Number the update. If nothing changed, say that in the first line.
Re: [CUSTOMER] / [SITE CODE] — service impact since [START HH:MM ET] — update [N] — next update [NEXT HH:MM ET]
Update [N] at [HH:MM ET (HH:MM LOCAL)]
Status: [unchanged / improved / worse / failed over / still investigating]
Impact now: [what users can and cannot do, this hour]
What changed since the last note: [one to three bullets, or “No change.”]
Tickets: internal [ID]; carrier [ID] if open
Evidence (if useful): [one sentence, or “redacted chart attached / available on request”]
Owner: [NAME]
Next update: [HH:MM ET], or sooner if status changes.
If you promised 30 minutes and you are on a carrier hold, the update is still due. Write “No change; still with the carrier on ticket [ID]; next update [TIME].” That is the whole email.
Template 3 — Restoration notice
Send this when the user path works, confirmed from more than a single probe. If the site is up on backup and the primary is still dead, this is a restoration of service, not of the primary circuit. Say which.
Re: [CUSTOMER] / [SITE CODE] — service restored [HH:MM ET] — primary [restored / still down, backup in use]
Service at [SITE] is working again from the user path as of [HH:MM ET (HH:MM LOCAL)].
Confirmed how: [user report + probe / two probes / LCON walkthrough — pick what you actually have]
Duration: [START] to [END] ([N] minutes)
What was affected: [services]
What remains open: [primary circuit still down / carrier ticket [ID] open / monitoring only / nothing]
Residual risk: [running on backup / reduced capacity / voice still degraded / none observed]
RCA: we will send a short summary by [DATE], or on request.
This notice is not a root-cause report and not an SLA credit filing.
Template 4 — RCA summary
This is a close-out, not a novel. If you do not have a confirmed cause, say so and keep the alternatives. Correlation groups signals; RCA is the claim about why — and a claim needs evidence.
[CUSTOMER] / [SITE CODE] — incident summary [DATE] — [ONE-LINE CAUSE OR “cause not confirmed”]
Incident: [SITE], [START] to [END] [TZ labels], [N] minutes.
Impact: [who, which applications, whether backup carried production].
Timeline: [detect / notify / ticket / failover / restore] — four or five timestamps, not the alert dump.
Cause (at the level of evidence): [e.g. “Primary carrier handoff unreachable; firewall and LAN remained up; carrier ticket [ID] attributed to [their wording, quoted].”]
Ruled out: [power, LAN, firewall crash, DNS, change in the window — only what you tested].
Evidence retained: [ticket IDs; redacted loss/latency chart for [window]; no raw management addresses in this note].
Corrective actions: [owner — action — due date]. If none, say “no durable change identified; watching [what] for [how long].”
Follow-ups: [SLA credit review Y/N and who owns the clock; extra monitoring; nothing].
This summary is operational. It is not a legal admission and not a substitute for the carrier's own close-out.
What the four messages look like together
A branch loses its primary circuit at 08:42 ET. Backup comes up. Users stay working. The wrong first email is a list of down objects. The right sequence is:
- 08:47 — Initial: site, failover in effect, users working, carrier ticket opening, next update 09:17.
- 09:17 — Update 1: no change, ticket [ID] open, next update 09:47.
- 10:08 — Restoration of primary once the handoff is back and a user path is confirmed; residual: none, or “watching for flaps.”
- Next business morning — RCA summary: 86 minutes, failover successful, cause at the evidence you have, SLA-credit owner named if the contract clock is running.
Same incident. Four messages. Nobody had to reconstruct it from a chat history.
Communication checklist
One incident, one owner, one thread. Times — ET and local, zone labels on every timestamp. Impact before cause. Next update time in every message until restoration. Backup stated honestly. No secrets, no other customers, no raw dumps. Restoration confirmed on the user path. RCA after evidence, not during the outage. If a credit clock exists, name the owner on the RCA — do not let the claim die in the inbox.
Bottom line
Outage communication fails in two directions: silence, and a stream of uncorrelated alarms. The fix is four templates and a clock you actually keep.
Write the impact, the residual risk and the next time you will write. Leave the diagnosis until you have it. Leave the credit filing to the person who owns that deadline.
Frequently asked questions
When should I send the first outage notification?
As soon as you can state the site, the impact, the start time and the next update time. Do not wait for root cause. An early message that says the cause is not yet confirmed is better than silence while users invent one.
How often should I send incident updates?
On the interval you promised in the last message, whether or not the facts changed. For a customer-facing site outage, 30 minutes is a workable default. Send an unscheduled update only when status, impact or ownership actually changes.
When is a restoration notice appropriate?
When the affected service is working from the user's path, not merely when a probe recovered. State what was restored, when you confirmed it, and what remains open. A restoration notice is not a root-cause report.
What belongs in an RCA summary?
Timeline, impact, confirmed cause at the level of evidence you have, what was ruled out, corrective actions with owners, and what you will watch. It is a short operational record, not a legal brief and not a transcript of every alert.
What should I not say in an outage email?
Do not guess a carrier, a person or a vendor. Do not publish internal IPs, SNMP strings, credentials, other customers' sites, or raw traceroute dumps. Do not promise an ETA you do not have. Do not say fully resolved while production is still on the backup path unless you say so.
Can I attach monitoring charts to a customer update?
Yes, if you redact management addresses, unrelated sites and credentials, and if the chart is the evidence for the sentence you already wrote. Do not attach a full export or a dashboard URL that exposes other customers.
Should the first notification name the carrier?
Only after gateway-first isolation supports it. The first message can say primary WAN is unreachable and the carrier ticket is open without declaring the carrier guilty. Wrong attribution in the first email is how you spend the rest of the incident unsaying it.
Who should receive each type of message?
Initial and updates go to the people who feel the impact and the people who will be asked about it. Restoration goes to that same list. The RCA summary goes to a smaller operational list unless the customer asked for a written close-out. Do not CC a shared mailbox that auto-opens a second ticket.
Related articles
- What is event correlation in network monitoring? — one incident instead of eleven alerts, which is what these templates assume.
- How to file an ISP SLA credit claim — the billing follow-up that should be named on the RCA, not improvised from the restoration email.
- How to monitor your ISP SLA — the independent history these messages should be able to point at.
- How much does a network outage really cost? — why the restoration notice and the credit claim are different numbers.
- Network outage vs network degradation — say which one you are in; the templates work for both if you are honest about impact.
References
Communication principles cited here are checked against the named public documents. Links verified 7 September 2026. The templates themselves are ADAM Pulse operating practice, not a standard.
- NIST Special Publication 800-61r3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management— source for treating communication as part of incident response rather than an after-action courtesy. Its incident definition is scoped to cybersecurity; the operational outage sense used in this article is broader, and the templates are written for network operations rather than a cyber investigation.
- AWS Well-Architected Framework — OPS10-BP02: Have a process per alert— referenced for the principle that an alert without a defined response is a notification rather than an operational signal. These templates are the stakeholder-facing half of that response.
- ADAM Pulse — What is event correlation in network monitoring?— companion for collapsing related alerts into one incident before anyone writes the customer.
Managed network and communications services for organisations that need to know what their network is actually doing. USA Telecom Consulting is an SBA-certified Service-Disabled Veteran-Owned Small Business — SBA VetCert VSBC-52457469368. Part of the ADAM Pulse Network Operations Series.