How often should I post incident updates?

Pick a cadence you can keep (often 15–60 minutes), and always set a next update time. Predictability reduces support load.

Should we share the root cause during the incident?

Share what you know with confidence. If root cause is unclear, focus on impact and mitigation, and publish deeper analysis later.

What’s the difference between identified and fix in progress?

Identified means you understand the cause category. Fix in progress means you’re deploying a mitigation expected to improve metrics.

How do I keep updates consistent across teammates?

Use templates, keep a comms owner, and standardize placeholders like impact, scope, and next update time.

More free tools Related: postmortem template

Status Page Update Templates (Copy/Paste)

During an incident, the hardest part isn’t typing — it’s staying clear, consistent, and calm. These templates help you publish updates that set expectations without guessing.

Replace placeholders like [SERVICE], [IMPACT], and [NEXT UPDATE TIME]. Keep updates short, timestamped, and honest.

Templates

Each block includes short + detailed variants where it helps.

Investigating (short)

Acknowledge the issue and promise an update.

[TIME] Investigating: We’re investigating reports of [IMPACT] affecting [SERVICE]. Next update by [NEXT UPDATE TIME].

Investigating (detailed)

Add scope, symptoms, and what you’re doing now.

[TIME] Investigating: We’re seeing [SYMPTOM] impacting [SERVICE].

Impact: [IMPACT] (e.g., elevated error rates, timeouts, degraded performance).
Scope: [AFFECTED REGIONS/USERS/COMPONENTS].

We’re currently [WHAT WE’RE DOING] and will provide another update by [NEXT UPDATE TIME].

Identified (short)

Confirm you’ve found the cause (without oversharing).

[TIME] Identified: The issue has been identified and we’re working on a fix. Next update by [NEXT UPDATE TIME].

Identified (detailed)

Add cause category + mitigation plan.

[TIME] Identified: We’ve identified the cause as [CAUSE CATEGORY] affecting [SERVICE].

Impact: [IMPACT].
Current status: [WHAT’S WORKING vs WHAT’S NOT].

We’re [MITIGATION/FIX PLAN] and will post another update by [NEXT UPDATE TIME].

Mitigating / fix in progress (short)

Say what’s changing, and what users should expect.

[TIME] Fix in progress: We’ve implemented a mitigation and are monitoring results. Next update by [NEXT UPDATE TIME].

Mitigating / fix in progress (detailed)

Include mitigation steps and whether service is recovering.

[TIME] Fix in progress: We’ve [WHAT WE CHANGED] to mitigate [ISSUE].

Current impact: [IMPACT].
Current status: [RECOVERING / STILL DEGRADED / INTERMITTENT].

We’re continuing to work on a full fix and will share another update by [NEXT UPDATE TIME].

Monitoring (short)

State you’re watching for stability before closing.

[TIME] Monitoring: A fix has been implemented and we’re monitoring results. Next update by [NEXT UPDATE TIME].

Monitoring (detailed)

Confirm recovery signals and what you’re verifying.

[TIME] Monitoring: We’ve implemented a fix and service is recovering.

What we’re seeing: [METRICS SIGNAL] (e.g., error rates returning to baseline, latency stabilizing).
Remaining impact: [NONE / LIMITED / INTERMITTENT].

We’re continuing to monitor for stability and will post another update by [NEXT UPDATE TIME].

Resolved (short)

Close the loop and thank users.

[TIME] Resolved: This incident has been resolved and [SERVICE] is operating normally. Thanks for your patience.

Resolved (detailed)

Include high-level cause + prevention without blame.

[TIME] Resolved: The incident affecting [SERVICE] has been resolved.

Impact: [IMPACT] from [START TIME] to [END TIME].
Root cause (high level): [CAUSE SUMMARY].
What we did: [FIX SUMMARY].

We’re implementing follow-ups to reduce the chance of recurrence. Thanks for your patience.

Extras

Useful blocks for common situations outside the “standard” flow.

Degraded performance

Slowdowns, elevated latency, partial impact.

[TIME] Degraded performance: We’re investigating elevated latency affecting [SERVICE]. Some users may see slow responses or timeouts. Next update by [NEXT UPDATE TIME].

Intermittent errors

Flaky failures, partial outage, retries may succeed.

[TIME] Intermittent errors: We’re seeing intermittent failures affecting [SERVICE]. Some requests may fail and succeed on retry. We’re investigating and will update by [NEXT UPDATE TIME].

Third-party provider incident

When an upstream vendor is the bottleneck.

[TIME] Investigating: We’re investigating an issue impacting [SERVICE]. Initial signs point to a disruption with a third-party provider ([PROVIDER]).

We’re monitoring the provider’s status and working on mitigations where possible. Next update by [NEXT UPDATE TIME].

Scheduled maintenance (announce)

Set expectations ahead of time.

[TIME] Scheduled maintenance: We’ll be performing maintenance on [SERVICE] on [DATE] from [START TIME] to [END TIME] [TIMEZONE].

Expected impact: [IMPACT] (e.g., brief downtime, degraded performance, read-only mode).
We’ll post updates here as maintenance progresses.

Scheduled maintenance (in progress)

When the window begins.

[TIME] Maintenance in progress: We’ve begun scheduled maintenance on [SERVICE].

Current impact: [IMPACT].
Next update by [NEXT UPDATE TIME].

Scheduled maintenance (complete)

Close the maintenance window.

[TIME] Maintenance complete: Scheduled maintenance on [SERVICE] is complete and the service is operating normally.

Next update time line

A reusable single line for consistency.

Next update by [NEXT UPDATE TIME].

FAQ

A timestamp, the impacted service(s), user-visible impact, what you’re doing next, and when the next update will happen. Avoid speculation.

Pick a cadence you can keep (often 15–60 minutes), and always set a “next update by” time. A predictable schedule reduces support load.

Share what you know with confidence. If the root cause is still unclear, focus on impact and mitigation. Save deeper analysis for the postmortem.

“Identified” means you understand the cause category. “Fix in progress” means you’re actively deploying a mitigation or change and expect it to move the metrics.

Use templates, keep a single incident owner for comms, and standardize your placeholders (impact, scope, next update). Consistency builds trust.

Make incident updates effortless

If you want a customer-facing status page that looks good and keeps a clean incident history, UpDog status pages are designed for that workflow.

Explore UpDog status pages

More free tools