Of all the updates you write during an incident, the resolution update gets the least attention. The first one you agonize over — you're choosing your words carefully because everything is still uncertain. The progress updates you write quickly, under pressure. And then the incident ends, you deploy the fix, everything turns green, and you type something like "The issue has been resolved. Thank you for your patience" and close the tab.

That final update is the one customers remember most.

Not because it's the dramatic one. Because it's the last thing they hear. It's the update that determines whether a customer walks away thinking "this team handled that well" or "they clearly just wanted it to be over." Two or three sentences, written in the two minutes you're still at your desk before moving on, and the work of every update that came before it either lands or evaporates.

Most teams waste it. Here's how not to.

The four things a resolution update needs

A good resolution update does four things, in this order:

1. Confirms it's over. Unambiguously. Customers shouldn't have to infer that the incident has resolved from the badge color changing. The first sentence says it.

2. States when it started and ended. The time bound is what transforms a vague "things were broken" into an accountable record. Customers who missed the incident can gauge whether they were affected. Customers who lived through it can verify their experience against your claim.

3. Explains what happened. One sentence, in customer language. Not root cause for its own sake — just enough that a customer understands what broke and can decide whether it affected their data, their work, or their trust.

4. Points forward. What did you fix, or what are you watching? Customers don't need an action list. They need one sentence that signals the problem has been addressed and isn't just sitting there waiting to happen again.

That's the whole update. Four beats, one paragraph, a minute to write when you know what you're doing.

A concrete before and after

Here's the kind of update that gets written when the team wants to move on:

The issue has been resolved. We apologize for any inconvenience.

And here's the same incident with the four beats filled in:

This incident has been resolved. Between 2:14 PM and 3:07 PM ET (53 minutes), some customers saw errors when trying to complete a purchase. A temporary disruption in our payment system caused new orders to fail. We've restored service and confirmed checkout is processing normally. We'll publish a full write-up within 48 hours.

The second version isn't longer than it needs to be. It's three sentences — roughly 60 words. But a customer reading it at 4 PM, wondering why their team got an error two hours ago, now knows exactly what happened, whether their window matched, and that someone stayed with it until it was clean.

The language problem

The place where resolution updates most often break down is language. The team has just spent an hour or two in the diagnostic layer — looking at dashboards, reading logs, talking in shorthand. The jargon is ambient. And it leaks.

A few patterns to watch for:

Service names. "Our auth service experienced a failure" is internal. The customer doesn't interact with your auth service — they interact with your login page. Write what customers experienced, not what broke on your side. "Customers were unable to sign in" is the same information from the right angle.

Error codes and percentages. "A 3.2% error rate on the /api/orders endpoint" tells an engineer something, but it tells a customer nothing useful. Translate: "some customers saw errors when placing orders." Spare the denominator — customers aren't comforted by learning 96.8% of orders went through while theirs didn't.

Passive constructions that hide accountability. "Errors were experienced" is vague. "A configuration issue caused sign-in to fail" is accurate and still plain. You don't have to be technical to be specific — you just have to name the customer impact and what caused it.

Hedging that softens the close. "It appears the issue has been resolved" or "service seems to be recovering" keeps the incident open in the reader's mind. If you're not sure it's resolved, don't publish the resolution update yet. When you are sure, say so without qualifiers.

What to do with "we're still investigating root cause"

Sometimes the fix ships before you fully understand why it was needed. You're confident the customer impact is gone, but you're not ready to explain what happened because you don't know yet.

This is fine, and it shouldn't stop you from posting the resolution update. The update just says so:

This incident has been resolved. Between 11:30 AM and 12:18 PM ET, some customers couldn't load the dashboard. We've restored service, and the dashboard is responding normally. We're still investigating root cause and will share a full write-up within 48 hours.

Saying "we're still investigating" is more honest than a vague explanation you're not confident in — and it anchors the postmortem promise, which is what turns a one-paragraph resolution update into a longer-form explanation when you're ready to write it.

The "thank you for your patience" problem

Most resolution updates end with some version of "we apologize for the inconvenience" or "thank you for your patience." Neither is bad, exactly — but both are so automatic that they read as filler. Customers have seen these phrases appended to every company communication they've ever received. They land with no more weight than "best regards."

If you want to close with an acknowledgment, make it specific to the incident:

We know this came at a frustrating time — checkout errors during a peak period are exactly the kind of disruption we work hard to prevent.

Or skip the sentiment entirely and let the update stand on its own:

This incident has been resolved. [time bound, what happened, what's next.]

The resolution update earns its close through substance, not through apology language. A clear, specific, plainly worded update already communicates respect for the customer's time. Appending generic gratitude doesn't add to that — it just padds the word count.

The update you write vs. the one you send

There's a difference between the update that lives on your status page and the one your subscribers receive via email or Slack. Both start from the same text, but the email subject line and the opening sentence carry the full weight — because many subscribers will skim or read only that far.

The subject line should make the resolution clear before anyone opens it. If your notification system uses the incident title, update the title to reflect resolution: "Checkout errors — resolved" rather than "Checkout errors — investigating." If you control the subject separately, lead with the close: "Resolved: some customers saw checkout errors between 2:14 and 3:07 PM."

The notification is often the only thing a subscriber reads. If the subject line says the incident is resolved and gives a time window, they may never need to open the full update — and that's fine. A subscriber who learned what they needed from the subject line is a satisfied subscriber.

Timing

The resolution update belongs at the moment the incident is genuinely resolved — not when you think it might be, not an hour after you've confirmed, not the next morning when you find time.

Customers who subscribed to get notified of incidents subscribed to get notified of resolutions too. The update is their signal to stop worrying, stop refreshing, stop working around the problem. Posting it late — even an hour late — means customers spent that time in unnecessary uncertainty, and some subset of them may have made decisions (routed around your product, moved their work to a competitor, emailed your support queue) that they didn't need to make.

If you're confident the incident is over, write the update first, before you move on. Before the postmortem. Before the retrospective Slack thread. Before you close the incident in your dashboards. The update is the one thing that's for them, not you — and it takes three minutes.

PageCalm is a status page tool with an AI writer that drafts resolution updates in plain language, ready for your review. Try it free — no credit card required.

How to Write a Resolution Update That Actually Closes the Loop