Your monitoring just fired. You've got an internal alert. Now the question: do you update the status page? Not every issue needs public communication, but waiting too long destroys trust.
The Core Tension
Status pages exist for transparency. But posting every blip creates noise and alarm. The goal is to communicate when customers are impacted while avoiding unnecessary panic.
Two Mistakes to Avoid
- Never updating. Status page always shows green, even during obvious outages. Customers lose trust.
- Over-updating. Every 2-second timeout becomes an incident. Customers think you're unreliable.
A Framework for Decisions
Ask three questions before posting to your status page:
1. Is the customer impacted?
Not every internal alert means customer impact. Database replication lag might be scary internally but invisible to users.
- Internal-only issues: Alert your team, don't post publicly
- Degraded performance: Consider posting if noticeable
- Functionality broken: Definitely post
2. Can you fix it quickly?
If you can resolve in under 5 minutes, you might not need a status page update. The incident will be over before most customers notice.
Expected resolution < 5 min → Internal alert only
Expected resolution 5-15 min → Consider posting
Expected resolution > 15 min → Definitely post3. Are customers already noticing?
If customers are already reporting issues (support tickets, Twitter, etc.), you've lost the initiative. Post immediately.
What to Post
When you do update the status page, be useful:
Good Status Update
API Performance Degradation We're investigating increased latency on our API endpoints. Some requests may timeout or take longer than usual. We've identified the cause and are deploying a fix. ETA: 15 minutes.
Bad Status Update
Investigating Issues We're looking into some issues.
Automated vs. Manual Updates
upti.my can automatically create incidents when monitors fail. But should you enable this?
When to Use Auto-Incidents
- Complete outages. If your main site is down for more than 2 minutes, auto-create an incident.
- Critical path failures. Login, checkout, or core functionality.
- Off-hours. Nobody is awake to manually update.
When to Keep Manual
- Flaky monitors. False positives create noise.
- Internal services. Customers don't need to know.
- Known maintenance. Scheduled downtime is handled differently.
The Middle Ground: Auto-Detect, Manual Confirm
A balanced approach: monitoring automatically detects issues and drafts an incident, but requires human confirmation before posting.
1. Monitor fails → Alert fires
2. System drafts incident: "API returning errors"
3. On-call engineer reviews: Confirm, edit, or dismiss
4. Confirmed → Posts to status page
5. Auto-resolves when monitor recoversAlert Channels vs. Status Page
Internal alerts and status pages serve different audiences:
Channel Selection Guide
| Channel | Audience | When to Use |
|---|---|---|
| PagerDuty/Opsgenie | On-call engineer | Every customer-impacting alert |
| Slack #incidents | Engineering team | All incidents, even minor |
| Status page | Customers | Customer-visible impact only |
| Twitter/Email | All users | Major outages only |
📌Key Takeaways
- 1Not every alert needs a status page update
- 2Post when customers are impacted and can't be fixed quickly
- 3If customers are already complaining, you're too late, post now
- 4Auto-incidents work for clear-cut outages, not edge cases
- 5Match communication channel to audience
The goal is trust. Customers should believe your status page reflects reality. That means updating when things break, but not crying wolf over every blip.