Health check endpoint exists
Why it matters
NIST AU-2 requires that systems generate audit records for events sufficient to support incident investigation, and a health check endpoint is the single most important hook for external monitoring and orchestration systems. Without a dedicated health endpoint, uptime monitors are forced to check your homepage — which may return 200 even when your database is unreachable or your API is broken. Load balancers and container orchestrators (ECS, Kubernetes, Fly.io) also depend on health endpoints to route traffic and restart failed instances. A missing health check means your monitoring tools and infrastructure cannot reliably determine whether your application is actually functional.
Severity rationale
Medium because without a health endpoint, uptime monitors check the wrong signal and load balancers cannot automatically isolate degraded instances.
Remediation
Create a health endpoint at a standard path that returns HTTP 200 when the application is operational.
For Next.js App Router, create app/api/health/route.ts:
import { NextResponse } from 'next/server'
export async function GET() {
// Optional: verify DB connectivity
// try {
// await db.execute('SELECT 1')
// } catch {
// return NextResponse.json({ status: 'error', reason: 'db' }, { status: 503 })
// }
return NextResponse.json({
status: 'ok',
timestamp: new Date().toISOString()
})
}
Point your uptime monitor to https://yourapp.com/api/health and configure it to expect HTTP 200. For deeper health checks, add database and cache connectivity probes so the monitor fails fast when dependencies are down rather than when the load balancer times out.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Logging & Monitoring Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- nist:rev5 · AU-2 — Event Logging
- iso-25010:2011 · reliability
- soc2:2017 · A1.2 — Environmental protections, backup, and recovery infrastructure
- soc2:2017 · CC7.2 — Monitoring for anomalous system activity
Taxons
History
- 2026-04-18·v1.0.0·Initial import from saas-logging·automated
- 2026-07-06·v1.0.1·Add SOC 2 TSC mapping (A1.2, CC7.2) from the verified compliance crosswalk register (docs/compliance/).·by soc2-mapping-enrichment-ship-2