Outage Notification Templates for Every Stage of an Incident.

During an outage, the hardest thing to write is the first sentence. These templates give you a clear starting point for each stage of an incident, so your team can spend its attention on the fix instead of on wording.

Key takeaways

• Post the first update fast - within 10-15 minutes of confirming the problem.
• Say what is affected, what users will notice and when the next update comes.
• Don't guess the cause or promise a time you can't keep.
• Update on a schedule even when nothing has changed.
• Close with a short summary and, for big incidents, a follow-up.

What every update needs

Each message should answer four questions:

1. What is affected? Name the service or feature, not the server.
2. What do users experience? "Payments fail" is clearer than "elevated error rates".
3. What are we doing? One sentence is enough.
4. When is the next update? A time, not "soon".

Investigating

Use this as soon as you have confirmed real user impact. It is better to post "investigating" quickly than a perfect message late.

Identified

Share the cause in plain words once you are confident in it. Leave out internal names and blame.

Monitoring

Tell users what to do, if anything - retry, log in again, clear an app cache.

Resolved

A good resolved message states the time window, the impact, the cause and what will change.

Degraded performance

Scheduled maintenance

Post it several days ahead, then update it when work starts and when it ends. See planned maintenance and uptime for how this affects SLAs.

Writing tips

• Use the users' clock. Name the time zone.
• Avoid jargon. "Database replication lag" means nothing to most customers.
• Don't over-promise. "We expect" is safer than "it will be fixed by".
• Keep a cadence. Every 30 minutes for major incidents is a common rhythm.
• Use the same place. A status page gives everyone one link to follow, and noc724 can update its status automatically from your monitors.

Frequently asked questions

• Should we announce small incidents?

  +

  If users noticed, yes - a short note builds more trust than silence. Purely internal problems that nobody felt don't need a public post.

• Who should write the updates?

  +

  Pick one person per incident, separate from the engineers fixing it. That keeps updates regular without distracting the people doing the work.

• What if we don't know the cause yet?

  +

  Say so. "We are still investigating the cause" is honest and fine; a wrong guess that you have to retract later hurts more.