Why Incident Communication Is Hard
When something breaks, the technical problem is often not the hardest part. The hardest part is telling people what happened.
Incident communication is stressful. You're under pressure to fix the problem and simultaneously explain it to users. You don't have all the answers yet. The clock is ticking. Support tickets are piling up. Social media is buzzing.
Poor communication during incidents causes damage that lasts longer than the downtime itself. It creates:
- Panic among users who assume the worst
- Speculation on social media that spreads misinformation
- Loss of trust that takes months to rebuild
- Support ticket floods that overwhelm your team
"Silence creates more damage than downtime."
This guide is about doing incident communication in a way that builds trust, reduces panic, and keeps everyone informed without overwhelming them. It's about saying the right things at the right time in the right way.
The Two Extremes to Avoid
Most teams make one of two mistakes during incidents. Both cause problems.
Extreme 1: Saying Nothing
Some teams go silent during incidents. They want to wait until they fully understand the problem before saying anything. They think it's better to stay quiet than to admit something is wrong.
This backfires in three ways:
- Users assume the worst. If they can't load your site, they wonder if you've been hacked, if their data is lost, or if you've shut down.
- Social media fills the gap. People start posting "Is it just me or is X down?" and speculation spreads faster than facts.
- Support gets flooded. Without a public update, everyone reaches out directly. Your team spends hours answering the same question.
Example of saying nothing:
[Status page shows green. No updates. No acknowledgment.]
Meanwhile, users can't log in. They check Twitter. They email support. They assume the company doesn't know or doesn't care.
Extreme 2: Saying Everything
The opposite mistake is over-communicating. Posting updates every few minutes. Sharing every theory about what might be wrong. Debating internally in public.
This creates:
- Alert fatigue. People stop reading after the third update in 10 minutes.
- Confusion. Contradictory messages make it worse. "Database issue" becomes "Network problem" becomes "Third-party API failure."
- Loss of confidence. If you keep changing your explanation, users wonder if you know what you're doing.
Example of saying too much:
2:05 PM: "We're seeing elevated error rates on login."
2:08 PM: "Database replica lag detected. Investigating."
2:12 PM: "Actually might be Redis. Checking cache layer."
2:15 PM: "Update: Load balancer config issue suspected."
Users read this and think: Do they know what's broken? Should I wait or come back tomorrow?
The goal is to stay between these extremes. Communicate enough to inform and reassure, but not so much that you create noise or confusion.
What Users Actually Want to Know
During an incident, users have simple questions. They don't need technical explanations. They need enough information to make a decision.
1. Is there a problem?
Acknowledge it clearly. Don't leave them guessing if it's their device, their internet, or your service.
2. Does it affect me?
Tell them who's impacted. Everyone? Just users in one region? A specific feature?
3. Are you aware of it?
Let them know you've seen it. This alone reduces anxiety by half.
4. Is someone working on it?
Confirm that you're actively investigating or fixing the problem. They need to know it's not abandoned.
5. When should I check back?
Give them a time. Even if it's "We'll update within 30 minutes." It sets expectations.
They do not need logs, stack traces, or internal debates. They need to know if they should wait, work around it, or come back later.
Every incident update should answer at least three of these five questions. If your update doesn't help users make a decision, it's adding noise instead of clarity.
A Simple Framework for Clear Incident Updates
Good incident updates follow a simple structure. You don't need to be a communications expert. You just need four parts.
Incident Update Framework
Acknowledgement
Confirm that you're aware of the issue
Impact
Describe who is affected and how
Current Status
What you're doing right now
Next Update
When they should expect to hear from you again
Breaking Down Each Part
1. Acknowledgement
Start by confirming the problem exists. Use plain language. Avoid minimizing it.
"We're investigating reports that users are unable to log in."
2. Impact
Describe who is affected and what isn't working. Be specific if you can. If you're not sure yet, say so.
"This is affecting users across all regions. Login and signup are not working. The rest of the product is functioning normally."
3. Current Status
Tell them what you're doing right now. Keep it simple. You don't need to explain the fix.
"Our team is actively working on a fix. We've identified the root cause and are implementing a solution."
4. Next Update Timing
Always give them a time. This is critical. It manages expectations and reduces check-back anxiety.
"We'll provide another update within 30 minutes, or sooner if resolved."
Put these four parts together and you have a complete, clear update. Every time.
Writing Incident Updates That Calm, Not Alarm
The words you choose matter. Dramatic language causes panic. Technical jargon causes confusion. Vague updates cause frustration.
Principles for Clear Writing
- Use neutral language. State facts without adding emotion or drama.
- Avoid dramatic words. Skip "critical," "disaster," "catastrophic," or "emergency" unless it truly is one.
- Be precise without being technical. Say "login isn't working" instead of "authentication service degraded."
- Prefer short sentences. Long sentences are harder to read under stress.
- Avoid speculation. Don't guess. Say what you know and what you're checking.
Before and After Examples
Bad Example
"CRITICAL OUTAGE: Our entire infrastructure is experiencing catastrophic failures. Multiple systems are down. We're unsure of the cause but it might be related to a database issue or possibly a network problem. We're investigating everything. Stay tuned for updates."
Good Example
"We're investigating an issue preventing users from logging in. This is affecting all users globally. Our team is actively working on identifying the root cause. We'll update you within 20 minutes."
Bad Example
"We've deployed a hotfix to the Kubernetes cluster and are monitoring replica pod health metrics across availability zones. Redis cache invalidation is in progress. Database connection pool has been rebalanced."
Good Example
"We've deployed a fix and login is being restored gradually. Most users should be able to access their accounts now. We're monitoring to ensure stability. We'll confirm full resolution shortly."
The good examples are shorter, clearer, and give users the information they need without technical noise or alarmist language.
When to Share Updates (Timing Matters)
Knowing when to post an update is as important as knowing what to say.
Timing Guidelines
Initial Acknowledgment: Fast
Post within 5 to 10 minutes of confirming an incident. You don't need to know the cause. Just acknowledge it. Silence for 30 minutes feels like an eternity to users.
Progress Updates: Only When Meaningful
Post updates when you have real progress. Not every 5 minutes. If nothing has changed, don't post "no update" updates. Just stick to your promised timeline.
Avoid "No Update" Updates
Don't post: "Still investigating, no new information." Instead, extend your timeline: "We're still working on this. Next update in 20 minutes." The difference is subtle but important.
Always Promise the Next Update
Never leave an update without saying when you'll check in again. Even if it's "We'll update by end of day." This prevents users from refreshing every 30 seconds.
Typical Incident Communication Timeline
Internal team becomes aware of the issue
"We're investigating an issue affecting login..."
"We've identified the cause and are deploying a fix..."
"Issue resolved. Login is working normally. Thank you for your patience."
This timeline will vary. Some incidents resolve in 10 minutes. Others take hours. The pattern stays the same: acknowledge quickly, update when there's progress, and always set expectations for the next check-in.
Audience-Based Communication
Not all audiences need the same message. End users need simple updates. Internal teams need more detail. Tailor your message to who's reading it.
| Audience | Level of Detail | Channel |
|---|---|---|
| End Users | Simple. Non-technical. Impact-focused. | Status page, social media |
| Customers (B2B) | Slightly more detail. Business impact clear. | Email, status page, direct outreach |
| Internal Teams | Technical. Root cause. Mitigation steps. | Slack, internal wiki, incident channel |
| Stakeholders | Business impact. Customer sentiment. Timeline. | Email, executive summary doc |
Public vs. Internal Updates
Public updates should stay simple and jargon-free. Save the technical details for internal channels.
Public Update Example
"We're experiencing an issue with file uploads. Users may see errors when trying to upload documents. Our team is working on a fix. We'll update you in 30 minutes."
Internal Update Example
"S3 bucket policy misconfiguration is blocking uploads. Region us-east-1 only. Fix deployed to staging, testing now. ETA to prod: 15 min. Monitoring error rates in Datadog. Will need post-mortem on how this passed CI checks."
Use the right level of detail for the right audience. Your support team needs different information than your users. Keep public messages accessible to everyone.
Status Pages as a Communication Anchor
A status page is your single source of truth during incidents. It's where users go to check if the problem is on your end or theirs.
Why Status Pages Help
- Single source of truth. Everyone checks the same place. No conflicting information across channels.
- Reduces repetitive questions. Instead of answering "Is it down?" 50 times, you point to one page.
- Self-service information. Users can check status without contacting support.
- Avoids conflicting messages. You control the narrative instead of letting speculation spread.
A good status page shows:
- Current system status at a glance
- Active incidents with updates
- Historical incident timeline
- Subscribe options for notifications
Example: PerkyDash includes built-in status pages that let you post incident updates, show system status, and notify subscribers automatically.
You can set one up in minutes and have a professional communication channel ready before the next incident hits.
The status page becomes your anchor. Every other communication channel (email, social media, support) points back to it. This keeps everyone looking at the same information.
Common Mistakes That Cause Panic
Even well-intentioned teams make mistakes that increase anxiety instead of reducing it.
Overusing Red or Alarming Language
Not every incident needs a red banner and the word "CRITICAL." Reserve alarming visuals and language for truly severe situations. Otherwise, people stop taking them seriously.
Tip: Use yellow or orange for most incidents. Save red for complete outages.
Updating Too Frequently Without New Info
Posting "Still working on it" every 5 minutes adds noise. Users tune out. Only post when you have meaningful progress.
Tip: Stick to your promised timeline. If you said 30 minutes, wait the 30 minutes unless resolved sooner.
Changing Explanations Mid-Incident
Saying "It's a database issue" then "Actually a network issue" then "Turns out it was a config error" makes you look unprepared. Wait until you know before naming a cause.
Tip: Say "We're investigating the cause" until you're confident. Then share what you learned.
Posting Technical Jargon Publicly
Users don't need to know about Kubernetes pods, Redis cache misses, or DNS propagation delays. Translate technical problems into user impact.
Tip: Ask "How does this affect what the user sees?" and write that instead.
Forgetting to Close the Loop
The incident is fixed but no one posts a resolution update. Users keep checking. Trust erodes because they're not sure if it's truly resolved.
Tip: Always post a final "resolved" update, even if it feels obvious.
These mistakes are easy to avoid once you're aware of them. Build them into your incident response checklist.
Closing the Incident Properly
The last update matters as much as the first. It's your chance to restore confidence and close the loop.
What to Include in a Resolution Update
- Confirm resolution clearly. "The issue is fully resolved" not "We think it's fixed."
- Acknowledge the inconvenience. A simple "We know this disrupted your work" goes a long way.
- Briefly state what will improve. You don't need a full post-mortem. Just one sentence about prevention.
- Avoid defensive language. Don't make excuses. Own it, fix it, move forward.
Example of a Good Closing Message
"The login issue has been fully resolved. All users can now access their accounts normally."
"We know this disrupted your workflow and we apologize for the inconvenience."
"We've identified the root cause and are implementing additional monitoring to prevent this from happening again. Thank you for your patience."
Notice what's missing: no excuses, no defensive tone, no over-promising. Just facts, acknowledgment, and a simple commitment to do better.
After the resolution update, consider writing a more detailed post-mortem for interested users. But make that optional. Most people just want to know it's fixed and won't happen again.
Frequently Asked Questions
How often should I post incident updates?
Post your first acknowledgment within 5 to 10 minutes. After that, only post when there's meaningful progress. Set expectations in each update for when the next one will come. Avoid posting "no update" updates. Quality over quantity.
Should I share technical details during an outage?
Not in public updates. Users need to know impact and timeline, not stack traces or infrastructure details. Save technical information for internal teams and optional post-mortems. Translate technical problems into plain language about what isn't working.
Is it better to wait until I know the cause?
No. Acknowledge the incident quickly even if you don't know why it happened yet. Say "We're investigating the cause" and update when you know more. Silence causes more anxiety than saying "We see it and we're working on it."
How do I avoid causing panic during incidents?
Use neutral, factual language. Avoid words like "critical," "disaster," or "catastrophic" unless truly warranted. State what's affected and what you're doing. Keep sentences short. Set clear expectations. Panic comes from uncertainty, so reduce it with calm, consistent updates.
Should every incident be public?
Not necessarily. If the incident is internal-only or affects a tiny subset of users in a way they won't notice, you might handle it quietly. But if users can see it or are affected by it, communicate publicly. When in doubt, lean toward transparency.
What belongs on a status page update?
Four things: acknowledgment of the issue, who's affected, what you're doing now, and when you'll update again. Avoid technical jargon, speculation, or excessive detail. Keep it clear, short, and action-oriented. Users should read it in 10 seconds and know what to do.
What if I don't have a status page yet?
Set one up before the next incident. Use a tool that makes it easy, like PerkyDash or similar services. In the meantime, use social media or a prominent website banner. But a dedicated status page is the cleanest, most professional approach and reduces confusion.
Closing Thoughts
Incident communication is a skill. It improves with practice and structure.
Clear communication builds long-term trust. Users understand that software breaks. What they don't forgive is silence, confusion, or feeling left in the dark.
The framework in this guide gives you a repeatable way to communicate calmly and clearly every time. Acknowledge quickly. Be specific about impact. Share what you're doing. Set expectations for the next update. Close the loop when it's done.
You don't need to be a communications expert. You just need to care about keeping people informed and use a simple structure to do it.
Ready to set up a professional status page for your next incident?
Try PerkyDash Free14-day free trial • No credit card required • Set up in minutes