## TL;DR
A good status page update names what is degraded, who it affects, and what you are doing, in that order. Keep each update under 80 words, timestamp everything, and post on a schedule even when nothing changed. Customers check the status page to decide whether to file a ticket, so every unclear update costs you ten tickets.

## The query

```text
status page templates for degraded performance
```

## Use this when

- Response times or error rates are elevated but the service is up
- A feature is partially broken for some customers
- You need pre-written templates before the next incident
- Updates are going out inconsistent or too slow

## Not for

- Full outages (different severity, different wording)
- Scheduled maintenance announcements
- Internal incident war-room comms
- Postmortem writeups

## Steps

### 1. Post the first update within 15 minutes of detection

Speed beats completeness. "We are investigating degraded performance in [area]" with a timestamp is enough. The investigation details come later.

Expected output: first post live within 15 minutes, every time.

### 2. Follow the same three-part shape every update

What is degraded, who is affected, what is happening now. Same order, every time. Regulars learn to scan your updates in seconds.

Expected output: no update goes out missing any of the three parts.

### 3. Timestamp and version your updates

Every post carries a time and a short status word: Investigating, Identified, Monitoring, Resolved. Customers scrolling a long incident need to find the latest state instantly.

Expected output: status word plus timestamp at the top of every update.

### 4. Update on a clock, not on news

Every 30 minutes during degraded performance, with or without progress. "Still investigating, next update at 3:30pm" is a complete update.

Expected output: no gap longer than 30 minutes without a post.

### 5. Close the loop with a resolved note

When metrics are back to normal, say so and note how long it lasted. "Resolved at 4:12pm after 2 hours of degraded response times." Then stop posting.

Expected output: a final resolved update on every incident, no dangling "monitoring" forever.

## Ready-to-use template

```text
INVESTIGATING - [time, home_tz]
We are seeing slower than normal [response times / error rates] in [area].
Affected: [who, e.g. customers in the EU region / API users].
Our team is investigating. Next update at [time].

IDENTIFIED - [time, home_tz]
We found the cause: [one-line cause, plain words]. [Area] is still slower
than normal for [who]. We are [fix in progress / rolling back / scaling up].
Next update at [time].

MONITORING - [time, home_tz]
[Area] is back to normal speeds as of [time]. We are watching the numbers
closely for the next hour. Next update at [time], or sooner if anything changes.

RESOLVED - [time, home_tz]
Resolved. [Area] ran slower than normal from [start] to [end] ([duration]).
We will publish a summary of what happened within [timeframe].
```

## Variant phrasings

### degraded performance status page wording

The four templates cover the full lifecycle. Copy them into your status tool as presets.

### how to write a status update for slow service

Steps 2 and 3. The three-part shape plus the status word is the whole craft.

### status page copy for partial outage

Same templates, but say "partial" plainly: "Some customers in [region] are affected." Dont let people guess whether it is them.

## Why it happens

Status pages go wrong when engineers write them like changelogs, full of internal detail and missing the customer's question: "is it me, and should I wait?" The three-part shape answers exactly that. And the 30-minute clock exists because silence during an incident reads as "they dont know," even when the team is working hard.

## Edge cases

- Degraded but you dont know the scope yet: say so. "We are still determining who is affected" is better than guessing wrong and correcting later.
- It degrades, recovers, degrades again: post each change as its own update. A flapping incident with honest posts beats one "monitoring" post that is quietly wrong.
- Customers file tickets anyway: that is fine. Link the ticket back to the status page and close the loop there.
- The cause is embarrassing (a bad deploy, a config typo): say it plainly in the summary. Customers forgive mistakes; they dont forgive cover stories.
- Degraded performance that lasts days: switch from 30-minute updates to twice daily, and say you switched. "We are moving to twice-daily updates on this" manages the expectation.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_D0TwWaYh0CxG6XAiA8fHeA