Running a SaaS Beyond the Code: Maintenance, Monitoring, Backups and Incidents

How do I establish monitoring, backups, incident response and on-call processes without a large team?

Alert on a few user-facing symptoms rather than every metric, back up automatically with an offline or separate-account copy and prove it by restoring on a schedule, define two or three severity levels with a one-page runbook, keep a status page, write blameless post-mortems after significant incidents, and share on-call fairly with clear response expectations. Large-company practices such as Google's SRE guidance are useful as principles, but scale the numbers down to your team.

Minimum viable monitoring

Google's Site Reliability Engineering book (chapter 6, "Monitoring Distributed Systems") recommends that if you can only measure four things about a user-facing system, you measure the four golden signals: latency, traffic, errors and saturation. It also advises spending more effort catching symptoms (what users experience) than causes, and says every page should be actionable. For a small SaaS that translates into a short setup:

1. External uptime checks on the login page, a key API endpoint and a health endpoint that touches the database, from more than one region.
2. Error tracking in the frontend and backend, with alerts on new error types and spikes rather than every occurrence.
3. Latency and error-rate alerts on the main user journeys, using your host's or APM tool's metrics.
4. Saturation warnings for database connections, disk, memory and any queue backlog, routed to chat rather than paging.
5. Business heartbeats: alerts when sign-ups, payments or scheduled jobs stop happening, which catch silent failures that infrastructure metrics miss.

Send only urgent, user-affecting alerts to phones. Everything else goes to a channel someone reviews daily. If an alert fires and nobody needs to do anything, change or delete it.

Backups you have actually restored

The SRE book's chapter on data integrity makes the point that nobody really wants backups, they want restores, and that you only know you can recover your recent state if you actually do so. CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity, because ransomware often tries to find and delete or encrypt accessible backups. A common rule of thumb that fits this guidance is 3-2-1: three copies of your data, on two different types of storage, with one kept offsite or in a separate account. For a small SaaS:

• Use your managed database's automated backups and point-in-time recovery, and know the retention period on your plan.
• Export a regular copy to storage in a separate cloud account with restricted credentials and, where available, object lock or versioning, so a compromised production account cannot delete it.
• Back up file storage and configuration (infrastructure-as-code templates, environment variable names, DNS records), not just the database.
• Run a restore drill on a schedule: restore into a fresh environment, run the app against it, check record counts and a few known records, and write down how long it took.

Two numbers make backup decisions concrete. RPO (recovery point objective) is how much data you can afford to lose, which sets backup frequency. RTO (recovery time objective) is how long you can be down, which sets how practised and automated the restore must be. Write both down, check the restore drill against them, and only promise customers what the drill shows. Remember that restored backups may contain data that was deleted at a customer's request; re-apply those deletions before going live.

Severity levels and a one-page runbook

The SRE book's chapter 14, "Managing Incidents", suggests declaring an incident early, and treating something as an incident if you need a second team, the outage is visible to customers, or it is unsolved after an hour of concentrated work. It also separates roles: incident command, operational work and communication. In a team of two or three, one person fixes and one person communicates; if you are alone, set a timer to post status updates so they do not get forgotten. A runbook that fits on one page:

1. Declare the incident in a dedicated channel and pick a severity.
2. Assign who is fixing and who is communicating.
3. Communicate on the status page early, even if the message is only that you are investigating.
4. Stabilise first: roll back the last deploy, turn off a feature flag, scale up, or fail over before searching for root cause.
5. Keep a timeline of what was seen and done, with times.
6. Check for a security or data dimension. If personal data may be affected, start the breach assessment straight away, because GDPR's 72-hour notification clock starts on awareness; see our GDPR for SaaS guide.
7. Close with a final status update and schedule the post-mortem.

For security incidents specifically, NIST SP 800-61 Revision 3 (published April 2025, superseding Revision 2) gives incident response recommendations organised around the NIST Cybersecurity Framework 2.0. In our view it is a good reference when you formalise your plan or answer an incident-response question from a buyer.

Status page and blameless post-mortems

A status page on a separate host from your app (so it stays up when the app does not) lets customers check rather than email, and gives you a record of incidents to point to. After any SEV1 or SEV2, write a post-mortem. The SRE book's chapter 15, "Postmortem Culture", describes a blameless post-mortem as one that assumes everyone acted with good intentions on the information they had, and suggests deciding triggers in advance, such as user-visible downtime, any data loss, or an on-call intervention like a rollback. Keep it short: what happened, impact, timeline, contributing causes, what went well, and action items with owners and dates.

On-call for a small team

The SRE book's chapter 11, "Being On-Call", describes Google's practice: a target of at most two incidents per 12-hour shift, response times of around 5 minutes for user-facing services and 30 minutes for less time-sensitive systems, compensation for on-call time, and a minimum of eight engineers for a single-site rotation. Most startups cannot meet that rotation size, so the useful lesson is the principle behind it: on-call must be sustainable or people burn out. For a small team, in our view:

• Define coverage honestly. Business-hours response plus best-effort out of hours is a legitimate choice early on; just make sure your SLA and contracts say the same thing.
• Rotate weekly among everyone who can deploy and roll back, with a written handover.
• Page only for SEV1 out of hours; everything else waits for the morning.
• Give time back after a disruptive night, and track pages per week so you can see when alert noise needs fixing.
• Make the runbook usable by the least experienced person on the rota: where the dashboards are, how to roll back, how to post to the status page, who to escalate to.

If you are planning a product and want this operational setup designed in from the start, our SaaS development team can design monitoring, backups and runbooks in from the start, and every build we deliver comes with a 60-90 day warranty period.