SaaS uptime monitoring that follows the surfaces customers log into — auth, dashboard, API, and billing jobs — not just whether the marketing site answers.
A SaaS product fails in pieces long before it fails completely. Sign-in can break while marketing pages stay green, the API can slow under load while the dashboard renders, and a billing webhook can silently stop. Monitoring has to follow the surfaces customers log in to, not just whether the homepage answers.
Multi-tenant SaaS rarely goes down for everyone at once. A bad migration can hit one shard, one plan tier, or a single large tenant whose data triggers a slow path — and an aggregate "is the app up?" check averages that pain away. Monitor the shared critical paths (auth, the API gateway, the billing pipeline) closely, and add representative checks for distinct tiers or tenant paths so a partial outage is visible instead of hidden behind a green average. Back a public status page with the customer-facing checks so users get an answer without opening a ticket.
Put an HTTP check on the login and dashboard URLs, a content check on an authenticated health route, and heartbeat checks on the background workers that send onboarding and billing events. Use groups to keep the customer plane separate from internal tooling.
Do not treat a 200 on the marketing site as proof the app works. The pages that earn revenue are behind authentication, and those are exactly the ones a homepage check never touches.
List the endpoints, jobs, and components where an outage would reach the people you serve. Keep the first pass to production.
Use HTTP or content checks for web surfaces, TCP for raw ports, SSL certificate checks for HTTPS expiry, and heartbeats for scheduled work.
Put production, staging, and per-client checks in their own groups so routing and noise stay under control.
Adjust intervals and retry counts once real data shows which alerts were signal and which were noise.