When your SaaS goes down, the clock starts immediately. Customers hit errors, support tickets pile up, and the longer it takes you to notice, the worse the damage. For B2B SaaS especially, a 30-minute outage during business hours can trigger breach-of-SLA conversations, erode trust you spent months building, and push customers toward competitors who were already on their shortlist.

The frustrating part is that most SaaS outages are detectable within seconds — if you are monitoring the right things. The problem is not a lack of tools. It is that most teams either monitor too little (just the homepage) or monitor the wrong things (vanity metrics instead of critical paths).

This guide covers exactly what a SaaS product should monitor at each stage of growth, how to structure alerts so the right person gets paged for the right issue, and what happens when you skip it.

The 8 things every SaaS should monitor

Not all endpoints are equal. A blog page returning a 500 is embarrassing. Your login endpoint returning a 500 means nobody can use your product. Prioritize monitoring based on revenue impact.

1. Login and authentication endpoints

If users cannot log in, your product is effectively down — even if every other page works perfectly. Monitor your login page, OAuth callback URLs, and session validation endpoints. These are the front door to your product.

What to watch for: HTTP status codes (obviously), but also response time. A login endpoint that takes 8 seconds to respond is functionally broken even if it returns a 200. If your auth relies on an external provider like Auth0 or Clerk, you are also exposed to their outages — which makes monitoring your auth flow even more important.

2. Main app dashboard

The dashboard is the first thing users see after login. It typically aggregates data from multiple backend services — database queries, cache layers, maybe external APIs. That makes it a good canary. If the dashboard is slow or broken, something upstream is failing.

Monitor both the page load (GET request returning 200) and, if possible, a keyword check to verify the page actually rendered expected content rather than an error message wrapped in a 200 response.

3. API endpoints

If you have a public API, your customers' products depend on it. API downtime is not just your problem — it cascades into their systems. Monitor your most-used API endpoints, your authentication/token endpoints, and any endpoints that handle writes (creating, updating, deleting resources).

For a deeper dive on this, see our guide on monitoring APIs programmatically. If you serve an API to external developers, you should also be checking response body content, not just status codes — a 200 that returns {"error": "internal server error"} is still broken.

4. Payment and billing flows

Broken payments are silent revenue killers. Unlike a crashed dashboard, a broken checkout page does not generate support tickets — users just leave. Monitor your checkout page, subscription management endpoints, and critically, verify that your Stripe (or other payment provider) webhook endpoint is reachable and returning 200s.

A webhook endpoint that starts returning 500s will cause Stripe to retry with exponential backoff, eventually disabling the webhook entirely. By the time you notice, you have missed subscription renewals, failed payment retries, and plan change events. Set up a dedicated monitor for your webhook URL.

5. Background jobs and cron tasks

Most SaaS products have critical background work: sending emails, processing uploads, syncing data, generating reports. These jobs fail silently. Nobody notices until a customer asks why their report from three days ago never arrived.

Use heartbeat monitoring for this. Instead of CronAlert pinging your URL, your cron job pings CronAlert when it completes. If CronAlert does not hear from your job within the expected window, it alerts you. This is the only reliable way to monitor jobs that run on a schedule.

6. Third-party integrations

Your SaaS probably depends on services you do not control: OAuth providers (Google, GitHub), email delivery (SendGrid, Resend, Postmark), CDNs, payment processors, analytics services. When they go down, your features break.

You cannot fix their outages, but you can detect them fast. Monitor your integration touchpoints — the actual URLs your backend calls, not the provider's status page. If your app calls https://api.sendgrid.com/v3/mail/send, monitor that. When it fails, you can switch to a backup, show a degraded-service banner, or at minimum communicate proactively to your users instead of getting blindsided by support tickets.

7. SSL certificates

An expired SSL certificate makes your site unreachable for every modern browser. It is one of the most preventable types of downtime, yet it catches teams off guard regularly — especially when certificates are managed across multiple domains and subdomains.

CronAlert monitors SSL automatically on every HTTPS check. No extra configuration needed. If your cert expires, has a broken chain, or fails the TLS handshake, you get alerted through whatever channels you have set up.

8. Status page

This one is meta but important: monitor your status page itself. During an outage, your status page is the one place customers go for information. If it is also down (because it shares infrastructure with your main app, which is a surprisingly common mistake), you have zero communication channel with your users.

Host your status page on separate infrastructure. CronAlert offers free hosted status pages that run independently of your app, so they stay up even when your product does not.

Monitoring strategy by company stage

You do not need 100 monitors on day one. What you monitor should grow with your product and team.

Pre-launch and MVP stage

Keep it simple. You need three things:

  • A monitor on your main app URL (the page users land on after login)
  • A monitor on your primary API endpoint or health check route
  • Alerts going to your personal Slack or email

This takes five minutes to set up with CronAlert and covers the basics. CronAlert's free plan gives you 25 monitors with 3-minute intervals — more than enough at this stage.

Post-launch: you have paying customers

Once money is changing hands, your monitoring obligations increase. Add monitors for:

  • Login and authentication endpoints
  • Payment/checkout flows and webhook endpoints
  • Background jobs via heartbeat monitoring
  • SSL certificate checks (automatic on HTTPS monitors)
  • A public status page so customers can self-serve during incidents

Set up at least two alert channels — for example, Slack for the team and email as a backup. You do not want a single point of failure in your alerting pipeline.

Growth stage: team and scale

At this point you likely have multiple engineers, an SLA to uphold, and customers in different regions. Your monitoring setup should reflect that:

Alert routing for SaaS teams

The number one complaint about uptime monitoring is alert fatigue. The solution is not fewer alerts — it is better routing. Not every alert needs to wake someone up at 3 AM.

Tier 1: page someone immediately

These are revenue-blocking failures. Login is down, the API is returning 500s, payments are broken. Route these to PagerDuty, SMS, or whatever your on-call system is. Response time target: under 5 minutes.

Tier 2: team notification, respond within an hour

Non-critical features are degraded. A background job missed its window, a third-party integration is failing, response times are elevated but the endpoint is still working. Send these to a Slack channel or Discord. The on-call engineer checks during business hours.

Tier 3: logged, reviewed weekly

SSL certificate expiring in 20 days, a non-critical page is intermittently slow, a staging environment is down. Email notification, reviewed in a weekly ops meeting.

The key principle: every monitor should have a clear owner and a defined response expectation. If nobody knows who is responsible for an alert, that alert will be ignored.

The cost of not monitoring

Abstract arguments about uptime do not land with founders. Concrete scenarios do. Here are failures we have seen SaaS teams experience because they were not monitoring the right things:

  • Stripe webhook endpoint broke during a deploy. No monitor on the webhook URL. Stripe retried for three days, then disabled the webhook. Result: 200+ subscription renewals were missed, requiring manual reconciliation and awkward emails to customers asking them to re-enter payment info.
  • OAuth provider changed their token endpoint. Login worked for existing sessions but new logins failed silently. Nobody noticed for 6 hours because the team only monitored the homepage. Every potential signup during that window bounced.
  • SSL certificate expired on the API subdomain. The main site used auto-renewal via Cloudflare, but api.example.com was on a manually managed cert. Mobile apps started failing, but the team only saw "network error" reports and spent two hours debugging before checking the cert.
  • Nightly data sync job stopped running. No heartbeat monitoring. Customers saw stale data for four days before someone filed a support ticket. The fix took 10 minutes — the detection took 96 hours.
  • CDN configuration change broke assets in one region. Users in Europe could not load the app, but the US-based team saw no issues. Without multi-region monitoring, they did not find out until a European customer churned and mentioned it in the exit survey.

Every one of these is detectable within 1-3 minutes with proper monitoring. The total cost of monitoring all of these endpoints with CronAlert is $5/month on the Pro plan, or $0 if you stay under 25 monitors.

Setting up SaaS monitoring with CronAlert

Here is the practical version. To get full SaaS coverage with CronAlert:

  1. Create an account at cronalert.com. Free plan includes 25 monitors.
  2. Add your critical endpoints — login page, dashboard, primary API route, payment webhook URL. Each takes about 30 seconds to configure.
  3. Set up alert channels. At minimum, add Slack or Discord plus email. Redundant alerting is important.
  4. Add heartbeat monitors for any background jobs or cron tasks. Your job pings a CronAlert URL on completion; CronAlert alerts you if the ping does not arrive on schedule.
  5. Create a status page. Takes two minutes. Gives your customers a place to check during incidents without flooding your support queue. See the status page setup guide.
  6. Enable keyword monitoring on critical pages to catch soft failures — pages that return 200 but render error messages. See keyword monitoring.

For a detailed walkthrough, see our complete setup guide. The whole process takes under 15 minutes for a typical SaaS with 10-15 endpoints.

As your team grows, upgrade to a plan with team monitoring, multi-region checks, and maintenance windows. See pricing for plan details.

FAQ

How many monitors does a typical SaaS need?

Most early-stage SaaS products need 5-15 monitors covering login, dashboard, core API endpoints, payment flows, and a health check. As you grow, expect 30-100+ monitors covering background jobs, third-party integrations, regional endpoints, and internal services. CronAlert's free plan covers up to 25 monitors, which is enough for most startups through their first year.

Should I monitor third-party services I depend on?

Yes. If your app depends on an OAuth provider, payment processor, email service, or CDN, you should monitor those integration points. You cannot control their uptime, but you can detect failures fast and communicate proactively with your users. Monitor your integration endpoints — the URLs your app actually calls — not the third-party's marketing site.

What check interval should I use for SaaS monitoring?

For critical endpoints like login, API, and payment flows, use 1-minute intervals. For less critical pages like marketing sites or documentation, 3-minute intervals are fine. CronAlert's free plan checks every 3 minutes; paid plans check every minute.

How do I avoid alert fatigue with SaaS monitoring?

Route alerts by severity. Send critical alerts (login down, payments broken) to PagerDuty or SMS. Send warning-level alerts (elevated response times, SSL expiring soon) to Slack or email. Use maintenance windows during deployments to suppress expected downtime. And consolidate — one team channel for non-critical alerts, direct paging only for revenue-impacting issues.

Is uptime monitoring enough, or do I also need APM?

Uptime monitoring and APM solve different problems. Uptime monitoring tells you whether your endpoints are reachable and returning correct responses — it is your first line of defense. APM tells you why something is slow or broken internally. Start with uptime monitoring. Add APM when you have the team and budget to act on the data it produces. Most SaaS teams under 20 engineers get more value per dollar from uptime monitoring.