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/demo; 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 |
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.
Further reading
Incident Post Template for Indie SaaS | StillOnline Status Page
Copy-ready incident phases: investigating, identified, monitoring, resolved. Publish on your StillOnline status page and alert owners via Telegram bot.
Status page vs social media during outages
Where to post outage updates: public status page vs social vs Telegram channel. Single source of truth with StillOnline.
Customer email template during an outage
Email all customers during an outage with a link to live StillOnline updates—distinct from status page subscriber notifications.
Degraded vs outage on your status page
When to use Degraded, partial outage, or major outage on StillOnline—so one bug does not look like total downtime.