Incident update cadence: the five-minute rule for indie SaaS
Silence during an outage reads as neglect. Enterprise runbooks target initial customer communication within minutes — indie teams can match that with a simple rule: first status page post within five minutes of confirming user impact, then scheduled updates even when nothing changed.
StillOnline gives you the hosted timeline at stillonline.tech/s/{id}; you write incident entries. Owner Telegram/Slack/email alerts tell you the probe failed — incident template supplies the words. Google SRE treats regular customer updates as part of incident command, not optional polish.
Quick answer
After StillOnline marks a check DOWN ( two consecutive failed probes — ~10 minutes on default 5-minute Free interval), publish Investigating on your status page within five minutes of confirming customer impact. Then update every 15–30 minutes, or post “No new information — next update at HH:MM UTC” as a valid entry. Subscribers on the public page get email on each published update. Pair with owner alerts so you hear before customers flood support.
Timeline from probe to post
| Time | Event | Your action |
|---|---|---|
| T+0 | First failed probe | Watch; may recover |
| T+~5 min | Second fail → DOWN | Owner alert fires |
| T+5–15 min | Confirm user impact | Investigating on status page |
| T+15–30 min | Ongoing | Update or “no news” post |
| Recovery | Two green probes | Resolved + summary |
StillOnline does not auto-write incident prose — only status from checks and your manual posts.
“No news” is a valid update
Customers prefer predictable silence over guessing.
Update (14:30 UTC): We are still investigating. No new information. Next update by 15:00 UTC.
This counts as communication in security reviews and reduces support tickets — B2B trust. NIST SP 800-61 recommends regular stakeholder updates during incidents even when root cause is unknown.
Cadence by severity
| Severity | First post | Follow-up |
|---|---|---|
| Major (product unusable) | ≤5 min | Every 15 min |
| Degraded (partial feature) | ≤15 min | Every 30–60 min — labels |
| Third-party (Stripe/Auth0) | ≤15 min | When vendor updates — third-party |
| Maintenance | Before window | Start + end posts — maintenance |
Related guides
- Incident post template
- Status page vs social media
- Customer email during outage
- Degraded vs outage labels
FAQ
Does StillOnline post incident updates automatically?
Auto-incidents reflect check DOWN/UP; human-readable timeline entries are your posts in the dashboard.
Five minutes from first fail or from DOWN?
Rule of thumb: five minutes from confirmed customer impact, which often follows the second failed probe (~10 min on Free).
How often do subscribers get email?
Each published incident update on the public page triggers subscriber notification (Google sign-in subscribers).
Can I slow updates on minor bugs?
Yes — use Degraded component scope and 30–60 min cadence; do not leave Major outage silent.