Operations · Runbook
What a runbook is, what belongs in it, a template, example entries for common problems and how to keep it alive.
Last updated: October 2026. Written by Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions.
Quick answer
A runbook is a practical, step-by-step guide to operating a system and handling common problems and incidents, written for someone who may not have built it. For a small SaaS or client portal, include a system summary, contacts and roles, access arrangements, routine checks, a release procedure with testing, rollback steps, common problems with symptoms and fixes, incident response, communication, backups and recovery and vendor information. Test it with a drill, update it after every incident and store it where it is reachable during an outage.
Key takeaways
- A runbook turns panic into procedure for whoever is on call.
- Include routine checks, release, rollback, common problems, incident response and recovery.
- Test it by having someone else follow it; update after every incident.
- Store it where it is reachable during an outage and protected from outsiders.
- Treat a user seeing another customer’s data as a serious incident.
In this guide
What is a runbook?
A runbook is a practical, step-by-step guide to operating a system and handling the situations that come up: a failed deployment, a payment problem, a user locked out, a suspected security issue. It is written for someone who is stressed and in a hurry, possibly not the person who built the system. For a small SaaS or client portal, a short runbook turns panic into procedure.
What belongs in a runbook?
| Section | Contents |
|---|---|
| System summary | What the app does, key components and where each lives |
| Contacts and roles | Who is on point, who decides, who the technical contacts and vendors are |
| Access | Where credentials are stored, who can approve emergency access |
| Routine tasks | Daily, weekly and monthly checks |
| Releasing changes | How to test, deploy and verify |
| Rolling back | How to undo a bad release |
| Common problems | Symptoms, likely causes and fixes |
| Incident response | Steps for outages, data issues and security events |
| Communication | What to tell customers and when |
| Backups and recovery | What is backed up, how to restore and how it was last tested |
| Vendor information | Support routes and account details for platform and services |
Runbook template
Routine checks
Daily: ________ (for example, check error alerts, failed payments, scheduled jobs ran)
Weekly: ________ (for example, review support requests and usage costs)
Monthly: ________ (for example, access review, test a restore, review integrations)
Release procedure
1. Make and test changes in the test version. 2. Run the release test checklist, including multi-account access tests. 3. Take a backup or note the version. 4. Deploy at an agreed quiet time. 5. Check key flows on live. 6. Record what changed and why.
Rollback
Steps to restore the previous state: ________ Who decides to roll back: ________ How to tell users: ________
Common problems
Symptom ________ Likely cause ________ First action ________ Escalate to ________ (examples: users cannot log in; emails not arriving; payments failing; page very slow; a user sees data they should not)
Incident response
1. Contain. 2. Log the time and facts. 3. Assess impact. 4. Notify the right people and, if required, regulators and customers. 5. Fix and verify. 6. Review and update the runbook.
Example entries for common problems
| Problem | First checks | Typical actions |
|---|---|---|
| Users cannot log in | Is the platform up? Did a recent release change login? Is it one user or many? | Check platform status, roll back a recent change, reset the account if one user |
| Emails not arriving | Provider status, sender authentication, spam folders, recent changes | Test sending, review sender authentication records (SPF, DKIM and DMARC), check the provider’s logs |
| Payments failing | Provider status, recent changes, error messages | Check the provider dashboard, test the flow, contact the provider |
| App slow | Recent release, unusually heavy job, usage spikes | Review scheduled jobs and searches. See workload units |
| A user reports seeing another customer’s data | Treat as a serious incident | Contain immediately, log, investigate and follow your breach procedure |
Keeping the runbook alive
- Test it: ask someone who did not write it to follow it in a drill.
- Update it after every incident, with what you learned.
- Review it quarterly and when systems change.
- Store it where people can reach it during an outage, which may not be inside the system itself.
- Keep contact details current.
- Keep it protected, since it describes your system.
What mistakes should you avoid?
- A long manual nobody reads in a crisis.
- Keeping it only in the system that has failed.
- Out-of-date contacts and credentials locations.
- No release or rollback procedure.
- Never practising the incident steps.
- No one owning it.
How can we help?
Simple Automation Solutions helps small SaaS and portal owners set up release routines, documentation and support runbooks, and provides support from $35 per hour, with no retainers or minimums. Builds start at $3,500. See our security guide, what maintenance involves and our guide to documenting an app. We do not offer round-the-clock cover unless it is specifically agreed.
Frequently asked questions
What is a runbook?
A practical, step-by-step guide to operating a system and handling common problems and incidents, written for someone who may not have built it.
What should a small SaaS runbook include?
A system summary, contacts, access arrangements, routine checks, release and rollback steps, common problems, incident response, communication, backups and recovery and vendor information.
How do I test a runbook?
Ask someone who did not write it to follow it in a drill, then update it with what they struggled with.
Where should I store it?
Where people can reach it during an outage and where it is protected, since it describes your system.
How often should I update it?
After every incident, when systems change and at least quarterly.
Want release, recovery and support procedures for your app?
Email us what you run. We will help you write a short, usable runbook.
Athar Ahmad, Certified Bubble.io Developer and Tech Architect, Simple Automation Solutions
About Simple Automation Solutions (SA Solutions)
Simple Automation Solutions is a Bubble.io development studio led by Athar Ahmad, a Certified Bubble.io Developer and Tech Architect. It builds web and mobile apps, client portals and SaaS products for founder-led businesses such as law firms, accounting firms, boutique agencies and consultants. Services include a free 30-minute Idea Audit, a $345 Discovery Sprint (a Product Requirements Document delivered within 24 hours, credited toward the build) and builds starting at $3,500. Website: sasolutionspk.com.
