---
title: Incident status update templates: copy-paste wording for every stage
description: Nobody writes well at 3 a.m. with checkout down. Here are status page updates you can copy and fill in for every stage of an incident (investigating, identified, monitoring, resolved), plus scheduled maintenance, partial outages, a provider's outage, a security incident and the follow-up, each with when to use it and the mistakes that cost you trust.
canonical: https://watchfor.io/blog/incident-status-update-templates
---

# Incident status update templates: copy-paste wording for every stage

2026-10-03 · WatchFor Team · Reliability · incidents, status-pages, communication, postmortem

Nobody writes well at 3 a.m. with checkout down. Here are status page updates you can copy and fill in for every stage of an incident (investigating, identified, monitoring, resolved), plus scheduled maintenance, partial outages, a provider's outage, a security incident and the follow-up, each with when to use it and the mistakes that cost you trust.

The first public update about an outage is usually written by the person
who is also trying to fix it. They are tired, stressed, and halfway through
a stack trace. That is how you get *"We are aware of a minor issue affecting
some users"* while every card payment fails.

The fix is boring: write the wording now, while nothing is on fire. This post
is a set of status updates you can copy into your runbook today. Each one has
a short note on when to use it and what to avoid. Fill in the brackets and
post.

If you're still deciding what belongs on a status page in the first place,
start with [status page best practices](/blog/status-page-best-practices).
This post is about the words.

## Five rules every update follows

Every template below is built on the same five rules. If you only remember
these, your updates will already be better than most.

1. **Say what customers see, not what broke inside.** "Card payments fail at
   checkout" helps a customer decide what to do. "payments-svc is
   crash-looping" helps nobody outside your team.
2. **Put a time zone on every time you write.** The page stamps each update,
   but the times *inside* your text ("since 14:05") need a zone. Use UTC if
   your customers are spread out, and write it every time.
3. **Promise the next update, then keep the promise.** "Next update by 15:30
   UTC" turns an anxious refresh loop into a calendar entry. Post at that time
   even if nothing changed. Silence reads as "they've stopped looking".
4. **No blame.** Not the cloud provider, not "a junior engineer", not "human
   error". Customers bought from you. "A configuration change we made" owns
   it without pointing at anyone.
5. **Don't shrink it.** If checkout is down for everyone, it isn't a "minor
   issue" and it isn't "some users". Pick the severity that matches the
   impact, and let the words match the severity.

Two smaller habits: write in plain words (no "degradation of the
ingestion pipeline"), and never give an ETA for the fix unless you would bet
your own money on it. Give the time of the next *update* instead.

## How to fill in the templates

Brackets are blanks. Keep the list of blanks short so the templates stay
usable under pressure:

- `[component]`: the name customers know (Checkout, API, Dashboard)
- `[symptom]`: what a customer sees (payments fail with an error)
- `[who]`: who is affected, as precisely as you know (customers in Europe)
- `[start]`: when it started, with a zone (14:05 UTC)
- `[next]`: when you'll post again, with a zone (15:30 UTC)

## The four stages of an incident

Most status pages, WatchFor's included, move an incident through four
statuses: **Investigating**, **Identified**, **Monitoring** and **Resolved**.
Each has a job. The [incident response playbook](/blog/incident-response-playbook)
covers what your team does at each stage; here is what you *say*.

### 1. Investigating

**When to use it:** the moment you know customers are affected, before you
know why. Speed beats detail. The goal of this update is one thing: *we know,
and we're on it.* Aim to post within about ten minutes of the first alert.

```text
Title: [component]: [symptom]

We're investigating reports that [symptom] for [who]. This started at
around [start]. We're working to find the cause and will post an update
by [next], or sooner if we learn more.
```

Filled in:

```text
Title: Checkout: card payments failing

We're investigating reports that card payments fail at checkout for
customers in Europe. This started at around 14:05 UTC. We're working to
find the cause and will post an update by 14:45 UTC, or sooner if we
learn more.
```

- **Do:** name the component in the title, so a skim of the page answers
  "is it the thing I use?"
- **Do:** say what still works if you know it ("browsing and sign-in are
  not affected"). It stops a flood of tickets about the parts that are fine.
- **Don't:** guess the cause. A guess you have to retract later costs more
  than saying nothing about the cause now.

### 2. Identified

**When to use it:** you know what's wrong and you're working on a fix (or
already rolling one out). This update should be the most specific one.

```text
We've found the cause: [cause in one plain sentence]. We're [what you're
doing about it]. Until this is fixed, [workaround, or "there's no
workaround"]. Next update by [next].
```

Filled in:

```text
We've found the cause: a change we made to our payment settings at 14:00
UTC rejected cards issued outside the US. We're rolling that change back
now. Until it's complete, PayPal payments still work. Next update by
15:15 UTC.
```

- **Do:** give a workaround if one exists. It's the most useful sentence in
  any incident.
- **Do:** say "a change we made" when that's what happened. Owning it reads
  as competence, not weakness.
- **Don't:** paste internal detail (hostnames, error codes, ticket numbers).
  They mean nothing to customers and leak more than you'd like.

### 3. Monitoring

**When to use it:** the fix is out and the symptom is gone, but you're
watching before you call it over. Skipping this stage is how incidents get
"resolved" twice.

```text
We've [fix, in past tense] and [symptom] stopped at [time]. We're
monitoring to make sure it stays fixed. [Anything customers need to do,
or "You don't need to do anything."] We'll post again by [next].
```

Filled in:

```text
We've rolled back the change and card payments have worked again since
14:52 UTC. We're monitoring to make sure it stays fixed. If a payment
failed for you between 14:05 and 14:52 UTC, you were not charged, and you
can try again now. We'll post again by 15:30 UTC.
```

- **Do:** answer the question everyone has: *was I charged? did my data
  sync? do I need to redo anything?*
- **Don't:** declare victory in this update. "Should be fixed" belongs here;
  "fixed" belongs in the next one.

### 4. Resolved

**When to use it:** the symptom has stayed gone for long enough that you'd
be surprised to see it come back. This is the update people read later,
so make it stand alone.

```text
This incident is resolved. From [start] to [end] ([duration]), [symptom]
for [who]. The cause was [cause]. We [fix]. [What customers need to do, if
anything.] We'll publish a short write-up of what happened and what we're
changing by [date].
```

Filled in:

```text
This incident is resolved. From 14:05 to 14:52 UTC (47 minutes), card
payments failed at checkout for customers paying with cards issued outside
the US. The cause was a change to our payment settings. We rolled it back
and have added a check that blocks this kind of change before it reaches
production. No one was charged for a failed payment. We'll publish a short
write-up by Friday.
```

- **Do:** include start, end and duration. Someone matching this incident
  to their own error logs next week will thank you.
- **Do:** promise a write-up only if you'll deliver it, and give a date.
- **Don't:** end with "We apologize for any inconvenience." It's the most
  skipped sentence on the internet. If you want to apologise, do it
  properly in the follow-up below.

## Partial outage or slowness

**When to use it:** things work, but badly or for some customers only:
slow pages, timeouts in one region, one feature down while the rest is fine.
These are the incidents teams are most tempted to skip, and customers notice
anyway.

```text
Title: [component]: slower than normal for [who]

Since [start], [component] has been [slow / failing for some requests] for
[who]. Most requests still succeed, but you may see [what they see:
spinners, timeouts, an error and a retry]. We're working on it and will
update by [next].
```

- **Do:** say it's partial, and say how partial if you know ("about one in
  ten requests").
- **Don't:** call it "minor" because it's partial. Partial for *you* can be
  total for the one customer in that region.

## Scheduled maintenance

Maintenance needs three posts: the announcement, the start, and the end.
Announce it early enough that people can plan around it. A week ahead is a
good default for anything with downtime; a day is the bare minimum.

**Announcement:**

```text
Title: Scheduled maintenance: [component] on [date]

On [date] from [start] to [end], we're [what you're doing, in one plain
sentence]. During this time [what customers will notice: "the dashboard
will be read-only", "the API may return errors for up to 5 minutes"].
[What doesn't change.] No action is needed from you.
```

**Running long:**

```text
The maintenance is taking longer than planned. [Component] is still
[state]. We now expect to finish by [new end]. We'll update by [next].
```

**Complete:**

```text
Maintenance is complete and [component] is fully available again.
```

- **Do:** be honest about what customers will notice. "May be briefly
  unavailable" is fine; "no impact expected" followed by 20 minutes of
  errors is how the next maintenance notice gets ignored.
- **Don't:** use "maintenance" for an outage after the fact. Unplanned is
  unplanned, even if you fixed it with a restart. [Maintenance windows done
  right](/blog/maintenance-windows-done-right) has the reasoning.

## When it's your provider's outage

**When to use it:** a cloud region, CDN, payment processor or email provider
you depend on is down, and your customers feel it.

```text
Title: [component]: [symptom]

[Symptom] for [who] since [start]. This is caused by an outage at one of
our providers, [provider], which is affecting other services too. We're
[what you're doing: "switching to a backup", "in contact with them",
"watching their status page"]. Next update by [next].
```

- **Do:** name the provider when it helps customers understand the scope,
  and link their status page if it's public.
- **Do:** say what *you* are doing. "It's not us" is not an update.
- **Don't:** use the provider as a shield. Customers chose you, and you
  chose the provider. Write "one of our providers", not "a third-party
  issue outside our control".

## Security incident

Security incidents are different. Saying too little looks like a cover-up;
saying too much can help an attacker or create legal problems. Involve
whoever handles legal and privacy **before** the first public post, and keep
the public text to facts you've confirmed.

There may be deadlines too. Under the EU's GDPR, a controller must notify
the supervisory authority of a personal data breach "not later than 72 hours
after having become aware of it" where feasible (Article 33), and must tell
affected people "without undue delay" when the risk to them is high, "in
clear and plain language" (Article 34). Those are notifications to a
regulator and to individuals, not status page posts, but your public
wording should never contradict them. ([Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj))

```text
Title: Security incident: [short, factual description]

On [date] we found [what happened, confirmed facts only: "unauthorised
access to one of our internal tools"]. We've [containment: "revoked the
access and rotated the affected credentials"]. We're investigating what
data, if any, was involved. [Action for customers, if any: "As a
precaution, please rotate API keys created before [date]."] We'll contact
affected customers directly. Next update by [next].
```

- **Do:** give customers something concrete to do, if there is something.
- **Don't:** publish technical details that would help someone repeat the
  attack (paths, versions, indicators) while it's still being contained.
- **Don't:** say "no data was accessed" until you can prove it.

## The apology and the write-up

After a serious incident, post a short follow-up a few days later. It's the
update that rebuilds trust, because it shows you learned something. A full
[blameless postmortem](/blog/blameless-postmortem) is for your team; this is
the public summary of it.

```text
Title: What happened on [date], and what we're changing

On [date], from [start] to [end], [impact in one sentence]. We're sorry.
[One sentence on why it mattered to customers: "Some of you lost sales
during that time."]

What happened: [2–4 plain sentences. Cause, why it wasn't caught, how it
was found.]

What we're changing:
- [Concrete change 1, with a date or "done"]
- [Concrete change 2]
- [Concrete change 3]

If you were affected and have questions, [how to reach you].
```

- **Do:** apologise once, plainly, near the top. "We're sorry" beats
  "we regret any inconvenience this may have caused".
- **Do:** list changes you'll actually make, with dates. Vague promises
  ("we're improving our processes") read as nothing.
- **Don't:** name individuals, and don't hide behind "a rare combination of
  factors". Every outage is a rare combination of factors.

## One incident, start to finish

Here is the payment incident from the templates as customers saw it on the
status page. Five posts in 90 minutes, each one useful on its own:

| Time (UTC) | Status | The update, shortened |
| --- | --- | --- |
| 14:12 | Investigating | Card payments failing in Europe since ~14:05. Next update by 14:45. |
| 14:31 | Identified | Cause: a settings change we made. Rolling back. PayPal works. Next by 15:15. |
| 14:58 | Monitoring | Payments working since 14:52. Nobody was charged for a failed payment. Next by 15:30. |
| 15:30 | Resolved | 47 minutes, cause, fix, a check added. Write-up by Friday. |
| Friday | Write-up | What happened, an apology, three changes with dates. |

Notice what isn't there: no "minor issue", no unexplained gaps, and no
update that left a reader wondering whether they need to do something.

## Where the templates live in WatchFor

A template is only useful if posting it takes seconds. In WatchFor the first
post often writes itself, and your templates take over from there.

**The first update is automatic.** With **Auto-publish incidents** on (the
default), a confirmed incident on a monitor attached to a status page becomes
a public incident within about a minute, with the affected component marked
and generic wording such as *"Login service disruption"*. Because WatchFor
only opens an incident once a failure is confirmed from several locations,
that first post doesn't go up for a single blip. When the internal incident
resolves, the public one resolves with it.

![A WatchFor status page for the Acme demo organization showing a Major outage banner, a scheduled CDN migration announced six days ahead, and an auto-published incident, Login service disruption, in the Investigating state with the default first update](/blog/incident-status-update-templates-public-page.webp)

That default line, *"We are investigating an issue and will provide updates
shortly"*, is honest but empty. It tells nobody what's broken or when to
check back. It buys you a few minutes, and the templates above are what you
replace it with.

**Then you take over the wording.** On the status page editor, **Post
update** on an open incident adds the next entry to its timeline, and **Post
incident** starts one by hand. Picking a status pre-fills a conventional line
("We have identified the issue and are working on a fix."), which you replace
with the filled-in template. You can also rewrite an automatic incident's
title and change its severity. Severity is what visitors see: *critical*
shows the affected components as down, *minor* and *major* as degraded. Your
wording is never overwritten by the automation, and every edit lands in the
activity log.

![The Post incident dialog on a WatchFor status page: title "Checkout: card payments failing", the Investigating template filled in as the initial message, status Investigating, severity Critical and the Checkout component selected](/blog/incident-status-update-templates-post-incident.webp)

**Decide how much the automatic post says.** Each status page component can
show *status only* (the default, "service disruption"), the *cause* in plain
words, or the *full detail* your team sees, which is meant for internal
pages. For a public page, status only plus a hand-written update a few
minutes later is the combination that reads best.

**Maintenance is announced from the maintenance window, never typed on the
page.** Turn on **Announce on status pages** in the window, and the
*Scheduled maintenance* notice appears ahead of time, moves to *In progress*
when the window starts, and to *Completed* when it ends. While it runs,
alerts are suppressed and the time doesn't count as downtime. Because there
is no way to post "maintenance" directly, nobody can relabel an outage after
the fact.

![The Edit maintenance window dialog: a one-hour CDN migration on three monitors with Suppress alerts, Exclude from SLA and Announce on status pages switched on for the Acme status page](/blog/incident-status-update-templates-maintenance.webp)

**The write-up can go on the page too.** When your team completes a
[post-mortem](/docs/alerting/postmortems) and an owner or admin switches on
**Publish to status page**, the public incident page shows the summary,
root-cause category and follow-up actions, without assignee names.

**Or post from your own tooling.** If your templates live in a runbook
script or a chat bot, the same updates go through the API. The first post:

```bash
curl -X POST https://watchfor.io/api/v1/status-pages/$PAGE_ID/announcements \
  -H "Authorization: Bearer $WATCHFOR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Checkout: card payments failing",
    "body": "We are investigating reports that card payments fail at checkout for customers in Europe. This started at around 14:05 UTC. Next update by 14:45 UTC.",
    "severity": "critical",
    "affectedComponentIds": ["'"$CHECKOUT_COMPONENT_ID"'"]
  }'
```

Each later update is a `PATCH` to the announcement with a new `body` and
`status`; `"status": "resolved"` closes it. The
[status pages API](/docs/api/status-pages) has the details.

## Common mistakes, collected

- **The update gap.** Promising an update at 15:30 and posting at 16:10.
  Set a timer when you post.
- **Resolving too early.** Skipping *Monitoring* and reopening an hour later.
- **Internal language.** Service names, ticket numbers, "p99".
- **Severity drift.** Starting at "minor" and never raising it as the
  impact grows. Change the severity the moment the impact changes.
- **One update for everything.** A partial outage, a provider outage and a
  security incident need different words. That's why there are templates
  for each.
- **No follow-up.** A big incident with no write-up leaves the last word
  to whoever complained loudest on social media.

Copy the templates into your runbook, fill in the component names you
already know, and decide now who is allowed to post. The
[complete status page guide](/blog/status-page-complete-guide) covers the
rest of the page these updates live on, and the
[incident updates docs](/docs/status-pages/updates) explain each status
and option in WatchFor.

---

Canonical page: https://watchfor.io/blog/incident-status-update-templates · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt