An incident response runbook gives a small team a dependable path through a stressful service or security event. It should help people detect the problem, limit harm, restore service, and communicate accurately. A long document that no one has practiced is less useful than a concise sequence with owners, commands, and decision points. The runbook should match the actual product and infrastructure rather than copy an enterprise template.
Define what triggers response
List the events that need immediate attention: customer data exposure, failed payments, unavailable sign-in, widespread errors, missing backups, or a compromised credential. Distinguish urgent incidents from ordinary support cases. Set a first contact and backup, with a way to reach them outside normal hours if the service promise requires it. A monitoring alert should identify the affected service and a first investigation step. Do not rely on customers as the primary detection system, but include a path for support reports to become incidents quickly.
Establish an initial picture
Record when the issue began, which tenants or workflows are affected, what changed recently, and what evidence is available. Check deployments, logs, metrics, job queues, external provider status, and database health. Use correlation identifiers where possible. Avoid changing many things at once before preserving the facts needed to find the cause. Assign someone to coordinate investigation and someone to communicate when the team is large enough; in a very small team, at least name who owns each responsibility. Keep a timeline as decisions are made.
Contain the harm
The right containment depends on the event. Revoke a leaked key, disable a vulnerable route, pause a faulty worker, or roll back a bad release. For a tenant-specific issue, target that tenant or item if the platform supports it rather than shutting down every customer. Protect data before optimizing availability when exposure is possible. Use managed commands and known recovery procedures instead of improvising production edits under pressure. Record what was changed so the team can reverse temporary controls later.
Recover and verify
Restore service through a tested rollback, forward fix, backup recovery, or provider failover. Verify user-critical workflows, not only that a process is running. Check data correctness after an incident involving writes; a green health endpoint does not prove invoices or posts are intact. Monitor error rate and customer reports for recurrence. If a backup is used, document its recovery point and any data gap. Keep temporary mitigations in place only with an owner and review date. A rushed recovery can create a second incident if verification is skipped.
Communicate honestly
Tell affected customers what is known, what service is unavailable, and when the next update will come. Avoid claiming a cause or impact before evidence supports it. Internal staff need a consistent status so support does not give conflicting answers. Security incidents may create legal or contractual notification duties; the runbook should point to the responsible decision maker rather than improvising law during an outage. After recovery, explain the practical impact and actions customers need to take, if any.
Learn and improve
Hold a short, blameless review of the cause, detection time, response, and recovery. Identify one or two changes that would prevent recurrence or shorten the next incident. Update tests, monitoring, and the runbook while details are fresh. Practice a tabletop scenario and a restore drill periodically. For an SMB SaaS provider, incident readiness is not a giant department. It is a small set of reliable habits that protects customer trust when normal operation fails. Review the runbook after each incident and remove steps that were too vague to help. Keep contact details, service locations, and rollback commands current. A practiced first ten minutes can limit damage more than a detailed document that nobody opens.