QUICCSTATUS
PricingDocs

Incident Communication Templates You Can Copy

Ready-to-use templates for status page incident updates: investigating, identified, monitoring, resolved, degraded performance, maintenance notices, and post-mortems — with the reasoning behind each.

By the QUICCSTATUS team · Updated

During an incident, writing is the last thing you have spare brain for — which is exactly when vague, panicky updates get published. Fix it by deciding the wording before the outage. Below are templates for every stage of an incident, ready to paste into your status page and adapt.

One principle behind all of them: every update answers three questions — what's affected, what we know, when we'll update next. If an update answers none of them, don't post it.

Stage 1 — Investigating

Post this within minutes of confirmed impact. Its job is acknowledgment, not diagnosis.

Title: [Service] — elevated errors / degraded performance We're aware of [symptom users see, e.g. "errors when loading the dashboard"] affecting [scope: all users / some users / region]. We're investigating and will post an update within [30] minutes.

Don't guess at causes here. An early wrong cause ("database issue") gets quoted back at you for the rest of the incident.

Stage 2 — Identified

We've identified the cause: [one plain-language sentence, e.g. "a failed deploy affecting the API"]. A fix is [being prepared / rolling out]. [Workaround if one exists: "In the meantime, X still works via Y."] Next update by [time].

Include the workaround if any exists — it's the single most useful thing you can give an affected user.

Stage 3 — Monitoring

A fix has been deployed and error rates are returning to normal. We're monitoring to confirm full recovery before resolving this incident. Next update by [time].

Resist resolving the moment graphs dip. A resolved→reopened incident reads much worse than thirty extra minutes of "monitoring".

Stage 4 — Resolved

This incident is resolved. Between [start] and [end] ([duration]), [what was affected and how]. The cause was [one sentence]. We'll publish a post-mortem with prevention steps [if you will: "by DATE"]. We're sorry for the disruption.

The apology matters and costs nothing. The duration matters because users will compute it anyway — better it comes from you.

Degraded performance (not a full outage)

Title: Slow response times on [service] [Service] is responding slower than normal ([rough numbers if known, e.g. "p95 ~4s vs the usual ~300ms"]). Requests are completing, but you may see timeouts. We're investigating; next update by [time].

Planned maintenance notice

Post ahead of time as a maintenance window, not as an incident — your uptime stats and your users' trust both depend on the distinction.

Title: Scheduled maintenance — [service] On [date] between [start–end, with timezone], we'll perform [plain-language description, e.g. "database upgrades"]. Expected impact: [none / brief interruptions / up to X minutes of downtime for Y]. We'll confirm completion here.

Third-party outage affecting you

Title: [Feature] unavailable due to upstream provider outage [Feature, e.g. "Payments"] is currently failing due to an outage at [provider]. Their status: [link]. Everything else is operating normally. We're tracking their recovery and will update within [60] minutes.

Name the provider and link their status page — it converts "their fault" from excuse into verifiable information. It's still your incident to close out.

Mini post-mortem (for the incident timeline)

Summary: [duration] of [impact] caused by [root cause in 1–2 sentences]. Timeline: [detected HH:MM] → [identified HH:MM] → [fixed HH:MM] → [resolved HH:MM] What we're changing: [1–3 concrete items, e.g. "adding a canary stage to deploys"].

Three lines is enough for most incidents. The "what we're changing" section is what separates a post-mortem from an apology.

Style rules that make all of these work

  • Times with timezones, always — "14:30 UTC", never "this afternoon".
  • User symptoms, not internals: "uploads are failing", not "the queue is backed up".
  • Commit to the next update time — and hit it, even if the update is "still working on it".
  • One incident per user-visible problem. Don't merge unrelated breakage into a mega-incident.

Pair these templates with automated uptime monitoring and alerts so you learn about incidents before your users do — templates only help if you know it's time to use them.

Put it into practice

Create a free status page with monitoring, custom domain, and incident management.

Start Free

Keep reading

Getting Started
How to Create a Status Page (Free, Step by Step)
Best Practices
Status Page Best Practices: What to Show (and What to Hide)