# Uptime monitoring is configured

- **Pattern:** `ab-002306` (`saas-logging.monitoring.uptime-monitoring`)
- **Severity:** critical
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002306
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002306)

## Why it matters

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.

## Severity rationale

Critical because without external uptime monitoring, downtime goes undetected until users report it, maximizing the revenue and reputation impact of every outage.

## Remediation

Set up an external uptime monitor that probes your app's health endpoint every 30–60 seconds and alerts your team immediately on failure.

1. Create a health check endpoint first (see `health-check-endpoint` check) — `GET /api/health` returning `{ status: 'ok' }` with HTTP 200.
2. Sign up for Better Stack Uptime (free tier: 10 monitors, 3-minute intervals) or UptimeRobot (free: 50 monitors, 5-minute intervals).
3. Add a monitor pointing to `https://yourapp.com/api/health` and configure alerts to email, Slack, or PagerDuty.

Document the setup in `docs/operations.md`:
```markdown
## 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.

## Detection

- **ID:** `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:
  1. Sign up for Better Stack Uptime (free tier: 10 monitors, 3-minute intervals) or UptimeRobot (free: 50 monitors, 5-minute intervals).
  2. Add a monitor pointing to your app's health check endpoint (see `health-check-endpoint` check).
  3. Configure an alerting channel (email, Slack, PagerDuty).

  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:

  ```markdown
  // docs/operations.md
  ## Uptime Monitoring
  - Service: Better Stack Uptime
  - Endpoint: /api/health
  - Interval: 60 seconds
  - Alert channels: Slack #ops, PagerDuty
  ```

## External references

- cwe CWE-778
- owasp A09
- nist AU-6
- iso-25010 reliability

Taxons: observability, operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-002306