Your homepage can be available while nobody can sign in. Your API can answer while a background worker quietly stops processing jobs. A useful first monitoring setup follows the places where customers get stuck.
Here is a starting set for a small SaaS. These are monitoring targets, not five promises that one HTTP request can prove.
1. The public entry point
Check the URL customers actually use, through its public hostname. A check against the origin IP skips parts of the path you want to observe. Look for the expected response and meaningful content, not just a server answering something.
2. Application readiness
Use a small, read-only endpoint that answers whether the application can serve its core workload. Document what it checks. A constant “OK” response is a process signal, not evidence that the database works.
Keep its output minimal. There is no reason for a public health response to contain database names, stack traces, or infrastructure addresses.
3. A representative read
Pick a harmless request that exercises real application code: fetching a public catalogue item, for example. Avoid a check that creates accounts, sends email, or charges a card. For protected services, use a dedicated least-privilege identity only when your tooling supports it securely.
4. Background-work freshness
If your product depends on scheduled work, record when it last completed successfully. A worker process being alive does not prove that yesterday's export finished. Expose a bounded freshness signal through your own health endpoint, rather than publishing customer job records.
5. The alert destination
This last one is a drill: verify that the alert reaches a place someone will notice. A correctly detected outage with an undelivered notification is still a blind spot.
Start small enough to understand
For each target, write one sentence: “If this fails, customers cannot ___.” If that sentence is difficult, decide whether the check belongs in diagnostics instead of urgent alerting.
You can explore the ZnowPulse demo before connecting a service. Start with the public entry point, then add the deeper checks your application actually exposes. For the next layer, read why a 200 OK response can hide a broken application.