Not every glitch deserves an email blast to your entire user base. Over-communicating minor issues trains customers to ignore your messages — a phenomenon called notification fatigue. When you eventually send a critical alert, it gets lost in the noise.
You need a decision framework for when and how to push notifications directly to customers, beyond simply updating the status page.
Key Decision Factors
1. Severity and Breadth
Is the issue critical (SEV1/SEV2) and affecting a large segment of users?
- Yes: Broad communication is warranted.
- No: A status page update is likely sufficient. Don't wake up customers who aren't affected.
2. Nature of Impact
The type of impact determines the urgency and channel of communication:
- Data Loss, Corruption, or Security Breach: These always require proactive, direct notification (email or SMS) to affected users, often with legal and compliance review before sending. This is non-negotiable — in many jurisdictions, it is also a legal requirement (GDPR, CCPA, HIPAA). Waiting for customers to discover a data breach on their own is a trust-destroying and potentially illegal choice.
- Temporary Service Unavailability: An in-app banner or status page update is usually sufficient. Customers who are actively trying to use the broken feature will see it; customers who aren't affected won't be unnecessarily alarmed.
3. Duration
- A 5-minute blip that resolves itself may not need any proactive communication at all, especially if it occurs during low-traffic hours.
- A multi-hour outage affecting core workflows definitely warrants proactive notification so users don't waste time troubleshooting their own setup, assuming the problem is on their end.
Choosing the Right Channel
| Channel | Best For | When to Use |
|---|---|---|
| Status Page | All incidents | Always — the baseline |
| In-App Banner | Active users hitting a broken feature | SEV1/SEV2, duration > 15 min |
| Critical, long-lasting issues; security events; issues requiring user action | SEV1 > 1 hour, any data/security event | |
| SMS | Highest-urgency alerts only | Security breaches, data loss, regulatory events |
| Social Media | Public-facing acknowledgment | When customers are already posting publicly |
The channel hierarchy matters. Don't send an SMS for a 10-minute API slowdown. Don't rely on a status page alone for a data breach. Match the urgency of the channel to the severity of the incident.
Interviewers sometimes ask: "How do you decide whether to send a customer email during an outage?" The weak answer is "when it's really bad." The strong answer references a decision framework: severity level, breadth of impact, duration, and nature of impact (availability vs. data/security). Specifically call out that data loss and security events always trigger direct notification regardless of duration, and that this is often a legal obligation, not just a best practice.