Most status page updates are useless.
"We are currently investigating an issue." — What issue? Which users are affected? When will you update again?
"Some users may experience intermittent issues." — Some? May? Intermittent? This tells me nothing.
Good status updates reduce customer anxiety, decrease support tickets, and preserve trust. Bad updates create more confusion than the outage itself.
This guide gives you ready-to-use templates, real examples, and a framework for writing status updates that actually help your users during their worst moment with your product.
The Four Stages of an Incident
Every incident follows a predictable arc. Your status updates should map to these stages:
Stage 1
Investigating
You know something is wrong. You don't know why yet.
Tone: Calm acknowledgment. "We know. We're on it."
Stage 2
Identified
You found the cause. You're working on a fix.
Tone: Specificity. "Here's what happened and what we're doing."
Stage 3
Monitoring
A fix is deployed. You're watching to confirm it works.
Tone: Cautious optimism. "We believe this is fixed. Watching closely."
Stage 4
Resolved
The incident is over. Systems are normal.
Tone: Confirmation + accountability. "It's fixed. Here's what happened. Here's what we'll do to prevent it."
Each stage has different information needs. An "investigating" update shouldn't try to explain root cause. A "resolved" update shouldn't skip the summary. Match your update to the stage.
Writing Rules That Apply to Every Update
Rule 1: Lead with impact, not cause
Users care about "what does this mean for me?" before "what went wrong technically."
Bad
"A database migration caused table locks on our primary cluster."
Good
"Users are unable to save changes in their dashboard. We've identified a database issue and are working on a fix."
Rule 2: Be specific about what's affected
Don't say "some services." Say which services.
Bad
"We're experiencing issues with some of our services."
Good
"Login and the API are currently unavailable. The marketing site and docs are unaffected."
Rule 3: Include a time reference
Every update should tell users when to expect the next one.
Bad
"We'll update as we know more."
Good
"We'll post our next update within 30 minutes, or sooner if the situation changes."
Rule 4: Use plain language
Your users might not be technical. Even if they are, clarity beats jargon during stressful moments.
Bad
"Elevated p99 latencies across our edge PoPs are causing intermittent 503 responses."
Good
"Some page loads are failing or very slow. This is affecting all users. We're working to fix it."
Rule 5: Be honest about uncertainty
It's okay to not know. It's not okay to pretend you do.
Bad
"This will be resolved in 10 minutes." (when you don't actually know)
Good
"We're actively working on a fix. We don't have an ETA yet but will update in 20 minutes."
Rule 6: Never blame the customer
Subtle but important.
Bad
"If you're experiencing issues..."
Good
"Users are experiencing issues with..."
The first implies it might be the user's problem. The second owns it.
Templates: Investigating Stage
You know something is wrong but don't know why yet
Template 1 — Complete outage
"[Service name] is currently unavailable. We are investigating the cause and will post an update within [15/30] minutes."
Template 2 — Partial outage
"We are investigating reports of [specific issue — failed logins / slow page loads / payment errors]. [Service X] and [Service Y] appear to be affected. [Service Z] is operating normally. Next update in [15/30] minutes."
Template 3 — Possible issue (not yet confirmed)
"We are investigating a potential issue with [service]. Some users may be experiencing [specific symptom]. We are working to confirm the scope and will update shortly."
Template 4 — Third-party dependency
"We are investigating an issue affecting [feature]. The issue appears to be related to one of our infrastructure providers. We are monitoring the situation and working with the provider to resolve it. Next update in 30 minutes."
Templates: Identified Stage
You know the cause and are working on a fix
Template 1 — Code/deployment issue
"We have identified the cause of the [outage/issue]: a recent deployment introduced a bug affecting [specific feature]. We are rolling back the change now. Estimated time to resolution: [X minutes]."
Template 2 — Infrastructure issue
"The [outage/slowdown] is caused by [brief description — database overload / network issue / storage failure]. Our team is [specific action — scaling resources / rerouting traffic / restoring from backup]. We expect to see improvement within [timeframe]."
Template 3 — SSL/certificate issue
"The issue is caused by an expired SSL certificate on [domain/service]. We are renewing the certificate now. Once renewed, it may take up to [X] minutes for the change to propagate. Users should be able to access the service normally after that."
Template 4 — Third-party issue
"We've confirmed the issue is caused by [our payment processor / our CDN provider / our authentication service]. The provider has acknowledged the issue and is working on a fix. We are monitoring their progress and exploring alternatives on our end. Next update in 30 minutes."
Note: Don't name specific vendors publicly (say "our payment processor" not "Stripe"). This is courteous and avoids complicating the vendor relationship.
Templates: Fix in Progress / Monitoring Stage
After deploying a fix, while verifying it works
Template 1 — Fix deployed, watching
"We have deployed a fix for [the issue]. Initial results look positive. We are monitoring closely to confirm full resolution. Some users may need to [refresh their browser / log in again / retry the action]. We will confirm resolution within [X] minutes."
Template 2 — Gradual recovery
"A fix is in place and we are seeing [service] recover gradually. [X%] of requests are now succeeding. We expect full recovery within [timeframe]. Users who are still experiencing issues should try again in [X] minutes."
Template 3 — Fix deployed, waiting for propagation
"The fix has been deployed but requires [DNS propagation / cache clearing / certificate distribution] which typically takes [timeframe]. Users should see improvement within [X] minutes. If you're still experiencing issues after that, please [hard refresh / clear cache / contact support]."
Template 4 — Partial fix
"We have partially resolved the issue. [Feature A] is now working normally. [Feature B] is still affected and we are continuing to work on a fix. Next update in [X] minutes."
Templates: Resolved Stage
The incident is fully over
Template 1 — Standard resolution
"The issue affecting [service/feature] has been resolved. All systems are operating normally. The incident lasted approximately [duration]. We will publish a detailed post-mortem within [24/48] hours. We apologize for the disruption."
Template 2 — With summary
"Resolved: [Service] is fully operational.
Summary: Between [start time] and [end time] (UTC), users experienced [specific impact]. The issue was caused by [brief root cause]. We deployed a fix at [time] and confirmed full resolution at [time].
Action items: We are implementing [specific preventive measures] to prevent this from happening again. A detailed post-mortem will be published within 48 hours."
Template 3 — After a long incident
"After [X hours] of disruption, [service] is fully restored.
We understand the significant impact this had on your work. Here's what happened:
• [Brief timeline]
• [Root cause in plain language]
• [What we're doing to prevent this]
We take this seriously and will share a complete post-mortem within 48 hours. Thank you for your patience."
Templates: Scheduled Maintenance
Planned downtime needs communication too.
Advance notice (1-7 days before)
"Scheduled maintenance: On [date] between [start time] and [end time] (UTC), [service] will be unavailable for approximately [duration]. During this time, [specific impact — users will not be able to log in / API will return 503 / dashboard will be in read-only mode].
We've scheduled this during our lowest-traffic period to minimize disruption. No action is required on your end."
Reminder (24 hours before)
"Reminder: Scheduled maintenance for [service] begins tomorrow at [time] (UTC). Expected duration: [X minutes/hours]. [Repeat impact details]. We will update this page when maintenance begins and when it's complete."
Maintenance started
"Scheduled maintenance for [service] is now in progress. Expected completion: [time] (UTC). We will update when complete."
Maintenance complete
"Scheduled maintenance is complete. [Service] is now fully operational. The maintenance was completed [on schedule / X minutes ahead of schedule / X minutes behind schedule]."
Templates by Incident Type
Login / authentication outage
"Users are currently unable to log in to [service]. [Sessions that were already active are / are not affected]. Our team has identified the cause and is implementing a fix. ETA: [X minutes]. We apologize for the disruption."
Payment / billing issue
"We are experiencing issues with payment processing. New purchases and subscription renewals may fail. No charges have been incorrectly applied. We are working with our payment provider to resolve this. Users who need to make urgent payments should [alternative action]. Next update in 15 minutes."
Data / API issue
"Our API is returning errors for [specific endpoints / all requests]. This affects [which integrations/features]. Existing data is safe and unaffected. Our team is working to restore API functionality. ETA: [timeframe]."
Performance degradation
"[Service] is currently experiencing slower than normal response times. Pages that normally load in [X] seconds may take [Y] seconds. Core functionality is available but degraded. We are scaling our infrastructure to resolve this. Users should not lose any data."
Email / notification failure
"Transactional emails (password resets, notifications, invoices) are currently delayed. Emails are queued and will be delivered once the issue is resolved — no messages will be lost. We are working to clear the backlog. ETA: [timeframe]."
Regional outage
"Users in [region] are experiencing [outage/slowdowns] when accessing [service]. Users in other regions are not affected. The issue is related to [our CDN / regional infrastructure]. We are rerouting traffic and expect resolution within [timeframe]."
What NOT to Write
Real examples of bad status updates (anonymized) and why they fail:
"We are aware of an issue."
Why it's bad: Which issue? What's the impact? When will you update?
"We are aware that login is currently unavailable for all users. Investigating now. Next update in 15 minutes."
"We are experiencing minor issues."
Why it's bad: "Minor" is dismissive. If a customer can't use your product, it's not minor to them.
"We are experiencing issues with [service]. We understand this impacts your work and are prioritizing a fix."
"Our engineers are working hard to resolve this."
Why it's bad: Of course they are. This adds no information.
"We've identified the cause (database connection pool exhaustion) and are deploying additional capacity. ETA: 20 minutes."
"Services may be affected."
Why it's bad: "May be"? Either they are or they aren't. Check before posting.
"Dashboard and API are currently affected. The marketing site and docs are operating normally."
(Complete silence for 2 hours)
Why it's bad: Users assume the worst. Support gets flooded.
Even "Still investigating. No new information. Next update in 30 minutes." is infinitely better than silence.
Post-Incident Communication
The incident ends when the fix is deployed. Trust recovery begins with post-incident communication.
Within 24-48 hours, publish a post-mortem that includes:
- What happened (plain language timeline)
- Who was affected and for how long
- Root cause
- How you fixed it
- What you're doing to prevent it from happening again
The post-mortem isn't just for transparency. It's a trust-building tool. Customers who see thoughtful post-mortems become more loyal, not less. They think "this team takes reliability seriously and learns from mistakes."
Share the post-mortem
- On your status page as an update to the incident
- Via email to affected users (for major incidents)
- On your blog (optional, for significant events)
- In your community channels
Conclusion
Writing good status updates is a skill, but it's not a complicated one. Follow these principles:
- 1 Speed over perfection — communicate within 5 minutes
- 2 Impact before cause — tell users what it means for them
- 3 Specific over vague — name what's broken and what's not
- 4 Honest over optimistic — don't promise what you can't guarantee
- 5 Regular over sporadic — update every 15-30 minutes, even with no new info
- 6 Follow up after — post-mortem within 48 hours
Bookmark this page. Copy these templates. When your next incident happens at 2 AM and your brain is foggy, you'll be glad you have them ready.
Related reading: Status Page Examples • Downtime vs Degradation • Causes of Downtime
Need a Status Page for Your Next Incident?
Emergency: create one in 60 seconds (free). Permanent: PerkyDash monitoring + status pages from €9.99/mo.
Frequently Asked Questions
How do I write a good status page update?
Lead with user impact, be specific about which services are affected, use plain language, include a time reference for the next update, and be honest about what you do and don't know. Avoid jargon, vague language, and minimizing the incident.
How often should I update a status page during an incident?
Update every 15 to 30 minutes during an active incident, even if there is no new information. A simple update like "still investigating, next update in 15 minutes" is far better than silence. Increase frequency for critical incidents.
What should a resolved status update include?
Confirm the issue is fixed, summarize what happened and how long it lasted, briefly explain the root cause, mention what preventive actions you're taking, and commit to publishing a detailed post-mortem within 24 to 48 hours.
Should I name third-party vendors in status updates?
No. Use generic descriptions like "our payment processor" or "our CDN provider" instead of naming specific companies. This is courteous to the vendor and avoids complicating the relationship.
What's the biggest mistake in status page communication?
Silence. Not communicating during an outage is almost always more damaging to customer trust than the outage itself. The second biggest mistake is using vague corporate language that tells users nothing about what's actually happening.
Related Guides
Emergency Status Page Guide
Create a status page in 60 seconds during a crisis.
TemplateIncident Post-Mortem Template
Structured template for post-incident analysis.
Status Pages12 Status Page Examples
Real examples from GitHub, Stripe, Cloudflare, and more.
EmergencyMy Site is Down — Now What?
Step-by-step plan for when things go wrong.