Incident response runbook for small teams

Small teams still have incidents

You do not need a twenty-person SRE org to need a runbook. When your SaaS API fails at dinner time or your store checkout breaks on Saturday, whoever is available needs clear steps — not improvisation. A one-page runbook plus free monitoring tools turns panic into procedure. The goal is not ITIL certification; it is recovering faster and communicating honestly while you fix things.

Every small team should have: named incident commander role (even if it rotates), external verification tools bookmarked, status page link ready, and escalation contacts for hosting and DNS providers.

Step 1: Confirm real outage

Before waking co-founders or posting public apologies, confirm the problem is real and external. Run Website Down Checker from your phone on cellular — not office Wi-Fi. If external check passes but you fail locally, suspect DNS cache, VPN, or browser extension — not production outage.

Run Uptime Monitor on critical URLs: homepage, login, API health, checkout. Log status codes and response times in incident channel. Ping Test shows whether slowness precedes hard failure.

Step 2: Triage by layer

Work top-down: DNS (DNS Propagation Checker, IP Lookup), TLS (SSL Checker), CDN and headers (HTTP Header Checker), application and hosting. Most small-team incidents are DNS, SSL expiry, or hosting panel outage — not mysterious code bugs. Check provider status pages before deep debugging.

Document findings as you go — post-mortems need timeline, not memory. Screenshot checker results with timestamps.

Step 3: Communicate early

Assign one person communication, one person technical if possible — avoid everyone debugging and nobody updating customers. Post Status Page acknowledgment within fifteen minutes of confirmed user impact: We are investigating reports of login issues, update in 30 minutes.

Pin status link in Slack, support macros, social bio during incident. Update at promised intervals even if no news — silence reads as abandonment. Plain language for customers; technical details in internal thread.

Step 4: Mitigate and recover

Common mitigations: rollback last deploy, disable recent plugin, toggle CDN proxy, renew expired certificate, fix DNS typo, restart application via host panel. One change at a time — verify with Website Down Checker after each. Multiple simultaneous changes obscure what worked.

Define rollback triggers before deploys — if error rate spikes, revert within fifteen minutes without debate. Speed beats root cause during active customer impact.

Step 5: All-clear and post-mortem

Declare recovery only when all critical Uptime Monitor checks pass twice consecutively over thirty minutes — flapping recovery causes trust damage. Post all-clear on status page. Schedule blameless post-mortem within three business days: timeline, root cause, action items with owners.

Blameless means fixing systems, not punishing people. Most recurring incidents trace to missing monitors or skipped checklists, not malice.

Runbook template to copy

Section A: Critical URLs and expected status codes. Section B: Tool links — all free tools bookmark folder. Section C: Provider contacts — hosting, registrar, CDN, payment. Section D: Status page URL and update templates. Section E: Escalation — who decides rollback, who talks to customers.

Review runbook quarterly. Update after architecture changes. New hire onboarding includes fake incident drill — run checks, write sample status update, find hosting login.

Prevention beats heroics

Weekly five-minute SSL Checker and Domain Expiry Checker prevent embarrassing preventable outages. Read SaaS status page communication guide for customer update standards. Runbooks turn heroes into habits — habits scale when team grows.

Roles when everyone is busy

Two-person startups need explicit incident roles: who talks to customers, who fixes technical issue, who logs timeline. Same person doing all three slows both communication and repair. Three-person teams can rotate Incident Commander weekly for practice even without active incidents.

Vacation coverage document lists who inherits runbook access, hosting logins, and status page edit permissions — update before holidays.

Severity definitions that stick

Define SEV1 customer-facing revenue stop, SEV2 major feature degraded, SEV3 minor issue with workaround — align with response times. Small teams cannot treat everything as SEV1 — burnout follows. Checkout down is SEV1; blog typo is not an incident.

Post severity in incident channel header so contractors and part-time contributors calibrate urgency immediately.

Customer support alignment

Support macros should link Status Page and request external check confirmation before escalating engineering. Train support to capture exact URL path, browser, and time zone — reduces cannot reproduce cycles. Weekly five-minute sync between support and engineering on recurring pain points feeds monitor URL list improvements.

After incidents, review tickets that opened before internal detection — gaps in monitoring often appear first in support queue trends.

Post-incident action item tracking

Every post-mortem action item needs owner and due date — monitor URL additions, runbook updates, automation fixes. Unowned action items recur identically next quarter. Add missing checkout URL to weekly checks within 48 hours of checkout incident, not eventually.

Share post-mortem summary company-wide for culture building — transparency about failures and fixes reduces rumor mill damage during incidents.

Summary

Reliable monitoring combines external HTTP verification, latency baselines, certificate and domain expiry checks, and honest customer communication during incidents. Qikot provides free monitoring tools runnable on demand without accounts — bookmark Uptime Monitor, Website Down Checker, and Ping Test for your critical URLs. Weekly five-minute reviews build habits that catch failures before customers do. Expand coverage as architecture grows; start with tier-one URLs that directly affect revenue and trust.

Post-incident action item tracking

Every post-mortem action item needs owner and due date — monitor URL additions, runbook updates, automation fixes. Unowned action items recur identically next quarter. Add missing checkout URL to weekly checks within 48 hours of checkout incident, not eventually.

Share post-mortem summary company-wide for culture building — transparency about failures and fixes reduces rumor mill damage during incidents.

Post-incident action item tracking

Every post-mortem action item needs owner and due date — monitor URL additions, runbook updates, automation fixes. Unowned action items recur identically next quarter. Add missing checkout URL to weekly checks within 48 hours of checkout incident, not eventually.

Share post-mortem summary company-wide for culture building — transparency about failures and fixes reduces rumor mill damage during incidents.

Summary

Reliable monitoring combines external HTTP verification, latency baselines, certificate and domain expiry checks, and honest customer communication during incidents. Qikot provides free monitoring tools runnable on demand without accounts — bookmark Uptime Monitor, Website Down Checker, and Ping Test for your critical URLs. Weekly five-minute reviews build habits that catch failures before customers do. Expand coverage as architecture grows; start with tier-one URLs that directly affect revenue and trust.

Frequently asked questions

How do I verify incident response runbook for small teams without expensive monitoring software?

Qikot provides free on-demand checks from our remote servers — no account or agent install. Use the Status Page Builder linked in this article, then confirm with related tools for SSL, DNS, or headers when symptoms persist.

Are Qikot checks accurate for website operators?

Checks simulate public HTTP paths customers use. They complement — not replace — internal metrics. External failure with internal green usually means DNS, CDN, TLS, or WAF issues between your origin and the internet.

How often should website operators run these checks?

Run tier-one URLs after every deploy and DNS change. Schedule weekly uptime and ping baselines, monthly SSL and domain expiry reviews, and always verify externally during incidents before closing tickets.

Does Qikot store my URLs or require login?

No user database. Checks are stateless and results cache briefly for performance. Do not submit secrets in URLs; use health endpoints without credentials in query strings.

What should I do when a check reports down?

Capture status code and timestamp, run complementary checks (headers, DNS, SSL), update your status page if customers are affected, and escalate to hosting with external evidence rather than browser screenshots alone.