CWE-778 and OWASP A09 both identify the absence of monitoring as a prerequisite for undetected failures. Uptime monitoring is the most basic layer: without an external service probing your application on a 30–60 second interval, you learn your app is down from user complaints — typically 15–60 minutes after the outage began. For a SaaS, every minute of undetected downtime is lost revenue and accumulated churn risk. NIST AU-6 (Audit Review, Analysis, and Reporting) requires continuous monitoring of system activity; uptime monitoring is the minimum viable implementation of this requirement for a public-facing service. The 'never skip' status of this check reflects that no deployed application is exempt — static sites go down too.
Critical because without external uptime monitoring, downtime goes undetected until users report it, maximizing the revenue and reputation impact of every outage.
Set up an external uptime monitor that probes your app's health endpoint every 30–60 seconds and alerts your team immediately on failure.
health-check-endpoint check) — GET /api/health returning { status: 'ok' } with HTTP 200.https://yourapp.com/api/health and configure alerts to email, Slack, or PagerDuty.Document the setup in docs/operations.md:
## Uptime Monitoring
- Service: Better Stack Uptime
- Endpoint: /api/health
- Interval: 60s
- Alert channels: Slack #ops
If you're on Vercel, enable Vercel Monitoring in your project dashboard — it adds uptime checks with no additional configuration.
ID: saas-logging.monitoring.uptime-monitoring
Severity: critical
What to look for: Enumerate all relevant files and Look for evidence of an external uptime monitoring service. Check: dependencies for uptime monitoring libraries or SDKs, .env.example for uptime monitoring service keys (Uptime Kuma, Better Stack, Pingdom, UptimeRobot, Cronitor, Checkly, Oh Dear, StatusPage), mentions in README or documentation of a monitoring service, configuration files for monitoring-as-code (e.g., Checkly config), or CI/CD pipeline steps that configure monitoring.
Pass criteria: At least 1 conforming pattern must exist. An uptime monitoring service is configured that will alert when the application becomes unreachable. This can be a standalone service (Better Stack Uptime, UptimeRobot, Pingdom), a platform feature (Vercel Monitoring, Railway health checks), or a self-hosted solution (Uptime Kuma). Evidence is found in config, dependencies, environment variable references, or documentation.
Fail criteria: No evidence of any external service checking whether the application is up. No uptime monitoring dependency, no environment variable references to a monitoring service, no mention in documentation.
Skip (N/A) when: Never — every deployed application needs uptime monitoring.
Detail on fail: "No uptime monitoring service detected — no monitoring dependencies, no environment variable references to uptime services (Better Stack, Pingdom, UptimeRobot, etc.), and no documentation of monitoring configuration"
Remediation: Without uptime monitoring, you learn your application is down when users complain — often hours after the fact. An external uptime monitor checks your app every 30-60 seconds and pages you immediately on failure.
The simplest approach for a SaaS:
health-check-endpoint check).If you're on Vercel, enable Vercel Monitoring in your project settings — it provides uptime checks and alerts.
Document the monitoring setup in your README or a docs/operations.md file so the next person knows it exists:
// docs/operations.md
## Uptime Monitoring
- Service: Better Stack Uptime
- Endpoint: /api/health
- Interval: 60 seconds
- Alert channels: Slack #ops, PagerDuty