A service interruption notice sample is most useful when you can drop it into email, a status page, or an SMS and change a few fields. Below are working templates for the three situations you’ll actually face — scheduled maintenance, an active emergency outage, and service restoration — along with the fixed elements every version needs and the legal rules that may dictate when and how you send them.
What Every Notice Must Contain
Lock these details down with your technical team before you write anything. Missing one creates confusion your support desk pays for later.
- Affected services. Name every system, platform, or feature that will be unavailable. “Some services” forces users to guess.
- Date and time window. Start time, expected end time, and time zone. If your users span zones, list two (for example, “2:00 AM–4:00 AM ET / 11:00 PM–1:00 AM PT”).
- Reason. One sentence, such as “database migration to improve performance” or “emergency security patch.” Users tolerate downtime better when they understand why.
- Geographic scope. If the outage is regional, say so. “Users in the northeastern United States” beats “some users.”
- Impact. What users can and can’t do. “You won’t be able to log in or access saved files, but automated billing will continue normally” is more helpful than “the platform will be unavailable.”
- Where to get updates. Link a status page, support email, or phone number. This single line prevents a flood of identical tickets.
- Urgent-contact path. If some users have time-sensitive needs, give them a direct escalation route.
Verify every timestamp against the maintenance schedule before the notice goes out. A notice that says 2:00 AM when the work actually starts at 2:00 PM does more damage than no notice at all.
Scheduled Maintenance Sample
Scheduled maintenance is the easiest notice to get right because you control the timing.
Subject line: Scheduled Maintenance: [Service Name] Unavailable [Date], [Time]–[Time] [Time Zone]
Body: We’re performing planned maintenance on [Service Name] on [Date] from [Start Time] to [End Time] [Time Zone]. During this window, [specific features or the entire platform] will be temporarily unavailable. This maintenance is for [brief reason, e.g., “a security update and infrastructure upgrade”]. No action is required on your end before or during the maintenance. We’ll send a follow-up confirmation once everything is back online. If you have questions, contact [support email or phone].
Send this at least 48 to 72 hours in advance. If your service level agreement specifies a longer lead time, follow that instead. Post it across every channel your users check: email, in-app banner, status page, and social media if your users expect it there. Make it nearly impossible for an active user to miss.
Emergency Outage Sample
Emergency notices are harder because you’re writing under pressure with incomplete information. The instinct is to wait until you know everything before saying anything. That instinct is wrong. Silence during an outage reads as ignorance or indifference. Say what you know, admit what you don’t, and commit to a time for the next update.
Subject line: Service Disruption: [Service Name] Currently Experiencing Issues
Body: We’re aware that [Service Name] is currently unavailable [or experiencing degraded performance]. Our team is actively investigating the cause. At this time, [describe known impact, e.g., “users are unable to log in” or “file uploads are failing”]. We’ll post our next update within [30 minutes / 1 hour]. For urgent matters, contact [support email or phone]. We apologize for the disruption.
Update at least every 30 minutes during an active incident, even if the update is just “still investigating, no new information.” Silence between updates is what drives users to social media and review sites. Each update should include a timestamp, what’s changed since the last one, and when to expect the next.
SMS and Short-Form Sample
A standard SMS message holds up to 160 characters before it splits into segments, so text alerts need to be ruthlessly concise. Three things only: what’s affected, when it’ll be fixed, where to find more detail. Everything else lives on the status page.
Example: “[Company]: [Service] is down. Est. fix by 4 PM ET. Updates at status.example.com”
That’s 73 characters. If your message runs past 160, most carriers split it into two segments, and some older devices display them out of order. For push notifications, aim for 30 to 40 characters per line so the full message is visible without expanding.
Restoration Notice Sample
When the service is back, close the loop. Users who saw the outage notice and changed their plans need to know it’s safe to return.
Subject line: Resolved: [Service Name] Fully Restored
Body: [Service Name] was fully restored at [Time] [Time Zone] on [Date]. [Brief one-sentence summary of what was done, e.g., “The database migration completed successfully and all systems have been verified stable.”] If you experience any lingering issues, try [clearing your browser cache / logging out and back in / restarting the app]. Contact [support email or phone] if problems persist. We appreciate your patience.
Include specific troubleshooting steps if the work involved changes that could affect cached data, saved sessions, or local configurations. Users who hit residual glitches after a restoration notice often assume the outage is still going rather than clearing a stale cache.
Communicating Through an Extended Outage
Short outages need one or two updates. Outages that stretch across hours or days need a cadence most teams underestimate.
- First 30 minutes. Acknowledge the issue publicly. State what’s affected and that you’re investigating. Don’t speculate on the cause.
- Every 30 to 60 minutes. Post an update with a timestamp, even if the only news is “no change.” Confirm the team is still working. Revise the estimated restoration time if the original no longer holds.
- At the cause identification point. Explain what went wrong in plain language. “A database configuration error” is fine. Avoid jargon or vendor blame-shifting.
- When a fix is deployed. Describe what was done and that you’re monitoring for stability before declaring the issue resolved.
Keep messaging consistent across every channel. If your status page says “investigating” while your social account says “resolved,” you’ve created a new problem. Give one person or team ownership of all outage communications so the messaging stays unified.
When Your Contract or the Law Dictates the Notice
If you sell a service under contract, your notification duties likely go beyond courtesy. Service level agreements commonly guarantee a monthly uptime percentage, often 99.9% or higher, and spell out financial consequences when you fall short. A 99.9% commitment means no more than about 44 minutes of unplanned downtime per month. Miss it and you typically owe service credits ranging from 10% to 50% of the monthly fee depending on how far uptime fell below target.
Most SLAs also require advance notice for planned maintenance, commonly 24 to 72 hours. Skipping that notice or sending it late can trigger credit obligations even if the maintenance itself goes smoothly. Read your own SLA, because the notification window and credit structure vary widely.
Force majeure clauses typically carve out natural disasters, widespread power failures, government actions, and third-party infrastructure failures. If the outage falls into one of these, the provider usually owes no credits. The exclusion generally still requires that you notify affected customers promptly and document the cause. The clause protects you from financial penalties, not from the duty to communicate.
Industry Reporting Rules
Some industries have mandatory reporting that goes beyond anything in your contract. Telecommunications providers must report network outages lasting at least 30 minutes to the FCC’s Network Outage Reporting System, with preliminary information due within 120 minutes of discovery and a final report within 30 days. Outages affecting 911 services carry a shorter deadline: notification to the affected 911 call center within 30 minutes of discovery and follow-up details within two hours.1Federal Communications Commission. Network Outage Reporting System (NORS)
In healthcare, if an outage results in unauthorized access to protected health information, HIPAA’s Breach Notification Rule requires you to notify affected individuals without unreasonable delay and no later than 60 days after discovering the breach.2U.S. Department of Health and Human Services. Breach Notification Rule The notification must describe the breach, the types of information involved, steps individuals should take, and what you’re doing to investigate and mitigate. Breaches affecting 500 or more individuals also require notification to the HHS Secretary and prominent media outlets in the affected area.
Consumer Protection Exposure
Even outside regulated industries, misrepresenting service availability to paying customers can create legal risk. Section 5 of the FTC Act prohibits unfair or deceptive acts in commerce, and federal examiners have flagged as potentially deceptive any practice of advertising a service that the provider does not intend or is not able to deliver. Hiding a known outage or lying about its cause to avoid refund requests fits within that framework.
Accessibility
Outage banners are useless if some of your users can’t perceive them. Under WCAG 2.1, status messages must be programmatically determinable by assistive technologies without requiring the user to interact with or navigate to the message.3World Wide Web Consortium (W3C). Web Content Accessibility Guidelines (WCAG) 2.1 In practice, your banner needs the correct ARIA role (typically role="alert" or role="status") so screen readers announce it automatically. Don’t use color as the sole indicator of severity: pair a red banner with a text label like “Critical” or “Scheduled,” and make sure your status page meets the same accessibility standards as your main product.
Post-Incident Report
For significant unplanned outages, publishing a post-incident report builds trust in a way no amount of “we apologize for the inconvenience” can match. A useful report covers four things:
- Impact summary. What broke, how many users were affected, how long it lasted.
- Root cause. What actually went wrong, in plain language. “A misconfigured load balancer sent all traffic to a single server, which overloaded” tells users you understand the problem.
- Response timeline. When you detected the issue, when you identified the cause, when you deployed the fix. Being transparent about detection delays shows honesty.
- Prevention steps. Concrete changes so this specific failure doesn’t recur. “We’re adding automated monitoring for load balancer configurations” is meaningful. “We’re committed to improving reliability” is not.
Publish within a few days of the incident, while details are fresh and users still care. Focus on systems and processes rather than individual mistakes; that framing makes future reports easier to write honestly.