Monitoring and Alerts for a Small SaaS

There are two ways a small SaaS finds out it is broken. A customer emails, or a monitor fires. The gap between those two is usually measured in hours, and it is the single cheapest reliability improvement available to you.

The mistake most teams make is not skipping monitoring — it is buying an observability platform, enabling every default alert, getting notified nineteen times in a week about a CPU spike that meant nothing, and muting the channel. Two months later the payments provider changes a response code and nobody notices for a day, because the channel with the alert in it is the channel everyone stopped reading.

A small product needs about six alerts. The work is choosing them and tuning them, not installing anything.

Alert on symptoms, not on causes

The organizing principle: page a human when a user is having a bad time, and only then.

CPU at 90% is a cause. It might mean a runaway process, or it might mean your app is efficiently doing exactly the work you wanted. Requests failing is a symptom, and it means something regardless of the cause. Cause-based alerts multiply endlessly — every resource, every dependency, every threshold — and each one has a false-positive rate. Symptom-based alerts stay a short list because your product only has a handful of ways to be broken from the outside.

Cause metrics are still worth collecting. Collect them as dashboards you look at during an incident, not as alerts that wake you up. The distinction between "monitored" and "alerted" is the one that keeps the list short.

The six that earn their place

For a typical small SaaS, this list covers the overwhelming majority of what actually goes wrong.

That last row is the one nobody has and everybody needs, so it gets its own section below.

Note what is absent: disk, memory, individual instance health, and the twelve default integration alerts your platform enabled for you. Turn those into dashboard panels. If high memory reliably precedes an outage in your app, alert on the outage symptom and use memory to diagnose it.

Watch for silence, not just for errors

The failure that survives longest is the one that produces no errors at all.

A webhook endpoint whose signature check started rejecting everything returns 200 to your monitor and processes nothing. A signup form that fails only on Safari looks perfectly healthy in aggregate. A background job that stopped being scheduled generates no logs, because it is not running. An email provider that quietly starts silently dropping mail leaves your application code cheerfully successful.

The counter-measure is alerting on absence. Pick the two or three events that never legitimately hit zero over a given window — new signups per hour during business hours, successful payments per day, webhook deliveries processed per hour — and alert when the count falls below a floor. Set the floor from your actual history with generous headroom; the goal is catching zero, not catching a slow Tuesday.

Do the same for scheduled work with a dead man's switch: the job pings a monitoring URL when it finishes, and the monitor alerts if the ping does not arrive. That catches "the cron stopped existing", which no error-rate alert can ever see. The reliability patterns behind those jobs are covered in background jobs for AI-built apps.

Check the money path from outside

Uptime checks against your homepage are close to worthless. The homepage is static, it is cached, and it will keep returning 200 long after the database is unreachable.

What you want is a synthetic check that does what a customer does: log in with a test account, load the main dashboard, and hit the endpoint that represents the product working. Run it every few minutes from at least two regions, and require two consecutive failures before paging so a single flaky network hop does not wake you.

Add a real transaction test in a test-mode account against your payment provider on a longer interval — hourly is fine. Payment integrations break in ways that produce no errors on your side at all: an expired webhook secret, a provider API version sunset, a key rotated in one environment and not the other. The gap between test-mode success and live-mode failure is a well-worn trap, described in when Stripe works in test but fails live.

Add cost alerts, because 2026 apps fail by billing

An AI-integrated product has a failure mode that traditional monitoring never contemplated: everything works perfectly and it costs you four thousand dollars overnight. A retry loop around a model call, an agent that recurses, a webhook that re-triggers itself — none of these look like errors, and all of them show up on an invoice.

Set a daily spend threshold with your model provider and your infrastructure host, and alert at 50% and 100% of it. Also alert on token volume per hour, since a spend cap tells you after the money is gone while a rate anomaly tells you while it is happening. Fixing an app burning API credits covers the code-level causes, and a hard rate limit on the offending path is the control that stops the bleeding.

Make each alert survivable

An alert that fires and gets ignored is worse than no alert, because it trains you to ignore the channel. Three habits keep the list trustworthy:

Require duration. Almost every threshold should be "for N minutes", not instantaneous. Momentary spikes are normal; sustained ones are incidents.

Give every alert a runbook line. Even one sentence — what this means, where to look first, the query or dashboard to open. Write it when you create the alert, because the moment you need it you will not be in a state to reason from first principles. This is the seed of an incident process that works when you are the only person available.

Review the ones that fired every week. For each, ask: was there action to take? If no, either raise the threshold, add duration, or delete the alert. A monitoring setup gets better through deletion far more often than through addition.

Route by severity too. Page-worthy alerts go to a phone. Everything else goes to a chat channel someone reads in the morning. When both live in the same place, the important one is invisible.

Frequently asked questions

What tools do I need for this? Less than you think. An uptime and synthetic-check service, an error tracker, and whatever metrics your hosting platform already exposes will cover the six alerts above. Add a dedicated observability platform when your questions outgrow that — usually when you have several services and need to trace a request across them. Getting the logging right first makes any tool you eventually buy far more useful.

What thresholds should I use? Measure before you set them. Take two weeks of normal traffic, find your typical error rate and p95 latency, and set the alert meaningfully above the worst normal value. Thresholds copied from an article fire constantly on one app and never on another, because they describe a system that is not yours.

Should a solo founder set up paging at night? Only for alerts where a 3am response genuinely changes the outcome — a full outage or a broken payment path. For everything else, a morning notification is fine, and the honest version of this is deciding in advance what you will not get up for. Writing that down is what makes the middle-of-the-night alerts credible.

---

If your first sign of trouble is a customer email, a working alert set is a day of setup that pays for itself the first time it fires. SprintX instruments small SaaS products with monitoring that catches real failures and stays quiet otherwise, tuned against your traffic rather than a template. Tell us how you currently find out things are broken and we will close the gap.