Not everything — the right things, in the right order. A checklist built from how SaaS applications actually fail.
A SaaS application needs monitoring at seven points: public availability, API endpoint health, frontend errors in real browsers, TLS certificates and DNS, performance against measured baselines, third-party dependencies, and deployments. That ordering is deliberate — it follows both how often each layer fails and how invisible the failure is without monitoring. This checklist works through each item with the reasoning attached, so you can adapt it to your product rather than following it blindly.
The failures that cost a SaaS business money are the ones users hit: cannot log in, cannot load the dashboard, cannot pay, cannot invite a teammate. So the monitoring checklist starts from the user's path inward — not from the infrastructure outward.
This inverts how many teams naturally think. Infrastructure metrics (CPU, memory, disk) are easy to collect and comfortable to watch, but they are proxies. CPU at 90% might be fine; CPU at 20% might accompany a total outage caused by a bad deploy. The user's path — DNS resolves, TLS handshake succeeds, page loads, scripts run, API calls return, payment completes — is the ground truth. Everything on the checklist below maps to a step on that path.
Every hostname a user or customer touches gets an availability check from outside your infrastructure: the marketing site, the app itself, the API base, the status page, per-customer subdomains if you issue them, and each customer site if you are an agency running client properties.
One check on /api/health is not API monitoring. Health endpoints exercise almost nothing — they typically return a static 200 without touching the database, the queue or auth. Meanwhile the endpoints that matter fail individually: a slow query degrades /api/orders while everything else stays fast.
Monitor the handful of endpoints that map to money and core journeys — login, the main data reads, checkout/billing — each with:
Modern SaaS frontends are applications in their own right: a framework bundle, client-side routing, dozens of API calls after first paint. Which means they fail after the server's job is done — an uncaught exception on route change, an unhandled promise rejection in a data fetch, a third-party script that breaks checkout. Server-side monitoring sees none of it; the 200 was delivered.
The fix is a small reporting script in the page: uncaught errors, unhandled rejections, failed network calls, grouped by error signature and judged against the site's own normal rate. Privacy matters here — the collector should strip query strings, tokens and anything personal, because error messages love to smuggle secrets.
Three failure modes have a date printed on them in advance:
These checks cost nearly nothing and prevent the most preventable class of outage in the industry.
The performance question for SaaS is not "is it fast?" but "is it as fast as it usually is?" — because usually is what users are habituated to, and deviation from it is what they feel. The checks you are already running collect latency for free; keep the percentiles (p50/p95) per endpoint over a trailing window, and alert on significant deviation from that measured normal rather than on a fixed number.
Fixed thresholds fail in both directions: 500ms is an emergency for an autocomplete endpoint and irrelevant for a report generator. Baseline comparison is the same rule applied fairly to both. Watch the trend as well as the level — a steady climb across hours is the signature of a leak or a filling pool, and it is visible long before any threshold trips.
Dependencies: your SaaS runs on other people's services — payments, email delivery, hosting, CDN, auth providers. When one of them breaks, your symptoms are indistinguishable from your own outage until someone thinks to check. Consume their status feeds automatically, map which of your services depend on which provider, and let the monitoring system say "checkout is failing because Stripe is down" — a sentence that saves an hour of misdirected debugging and stops forty duplicate alerts.
Deployments: the single highest-value correlation in monitoring. Most production degradation follows a change. Wire CI (GitHub, Vercel, or whatever ships your code) to record deployments into the monitoring timeline, so "latency doubled at 14:32" can be read next to "deploy landed 14:28". Correlation is not causation — the monitoring should present it as context, not verdict — but it is the correct first place to look, every time. MTTD drops sharply when the change log and the anomaly log are the same timeline.
A deliberately honest section, because checklist articles love to demand everything at once:
The checklist above is a solid afternoon of setup for a typical SaaS and covers the failure modes that actually generate support tickets. The startup edition cuts it down further for two-person teams.
Certificate checks have become a monthly matter rather than an annual one — why 47-day certificates change the checklist.
| Layer 1 | Outside-in availability checks on every user-facing hostname, 1–5 min, confirmed before alerting |
|---|---|
| Layer 2 | Per-endpoint API checks with expected status/content and latency recording |
| Layer 3 | Frontend error collection from real browsers, grouped and baselined |
| Layer 4 | Daily TLS expiry checks (warn ≥14 days), DNS verification, domain expiry |
| Layer 5 | Latency percentiles vs measured baseline — never fixed thresholds alone |
| Layer 6 | Dependency status feeds mapped to the services that rely on them |
| Layer 7 | Deployment events recorded into the monitoring timeline |
| Safe to defer | Log aggregation, tracing, box-level metrics on managed infra, synthetic journeys |
In order: outside-in availability checks on every user-facing hostname; per-endpoint checks on the APIs that map to login, core data and billing; frontend error collection in real browsers; TLS certificate expiry; latency baselines; third-party dependency status; and deployment events. This ordering follows how often each layer fails and how invisible each failure is without monitoring.
No. Health endpoints typically return a static 200 without exercising the database, queues or authentication, so they stay green through real failures. Monitor the specific endpoints users depend on, with expected status and content assertions and latency recording per endpoint.
If you run your own servers, yes, as a supporting layer. If you are on managed platforms — serverless, managed databases, Vercel-style hosting — the provider monitors the machines, and your effort is better spent on behavioural monitoring: availability, latency, errors and frontend health, which reflect what users actually experience.
Most major providers publish machine-readable status feeds (the Statuspage format is a de-facto standard). Consume them automatically and map each of your services to the providers it depends on, so an incident on your side is automatically explained when the cause is theirs — and so one provider outage produces one story instead of dozens of independent alerts.
Five minutes is the standard trade-off for most surfaces, giving worst-case detection latency of about ten minutes with confirmation. Tighten to one minute for anything carrying a strict contractual SLA. Certificate checks only need to run daily.
Yes — it is the highest-value correlation available. Most production degradation follows a change, so recording deploy events into the same timeline as your checks lets any anomaly be read next to what shipped just before it. The monitoring should present the deploy as correlated context to investigate, not as an automatic verdict of blame.
Merik's Digital Operations module covers this checklist as its core loop: register each site, app or API as an asset (per client, if you run client properties), and it gets outside-in availability checks with two-failure confirmation, per-endpoint latency recording, daily SSL expiry checks on HTTPS targets, and a 14-day latency/error baseline that makes deviation detectable. The merik.js snippet adds frontend error collection with grouping and privacy redaction built in.
Dependencies are first-class: mark which vendors each asset hard-depends on, and a Stripe or Cloudflare outage suppresses the pile-on while recording the incident. GitHub and Vercel webhooks put deploys on the same timeline as anomalies. Everything rolls up into an error-budget health score, early warnings when behaviour drifts, and a monthly SLA report per client — the checklist, running itself.
Every layer of application health, and how to roll them into one honest score.
APIs degrade before they die — latency drift, timeouts, error trickles. Monitoring that listens.
200-day certificates now, 47 by 2029. Renewal fails silently; monitoring catches it.