n8n API Health Check Monitoring Beyond the 200 OK

A 200 OK Can Be the Quietest Outage You'll Ever Have

The point of n8n API health check monitoring is to catch the failure a status code hides. A /health endpoint that returns 200 OK with a body of {"status":"degraded","db":"down"} is an outage your status-code check will sleep right through. Most workflows that rank for this read the status line and call it done.

The Website and API health monitoring system does mention analyzing JSON for "common health indicators," which is the right instinct, but it doesn't drill into per-dependency assertions. The service health monitor with double-verification and Slack alerts nails the two-strike debounce that kills false positives, but it checks status codes only and keeps no history. And n8n's own monitoring docs document the distinction most monitors ignore entirely: /healthz, /healthz/readiness, and /metrics are not the same signal.

n8n fits because asserting a response body is just one more check in the same flow as the status code. This post stays on the API layer, distinct from the page-level work in n8n uptime monitoring with Slack alerts.

What a Real API Health Check Asserts

A health check worth trusting reads more than the status line:

• Status code: the floor, not the ceiling
• Body assertion: parse the JSON, confirm status: ok and each dependency
• Liveness vs readiness: hit both endpoints, treat them as different signals
• Latency: flag a slow-but-200 response separately from a failure
• Double-verification: a second check before paging, to ignore one blip
• History: log every result so you can compute real availability
• Recovery: a resolved notice when the body goes green again

The API Health Pipeline

Schedule Trigger (every 5 min)
  → Code (load endpoints + their expected body shape)
  → HTTP Request (GET /healthz/readiness, continueOnFail: true)
  → IF (status 2xx?)
      → yes:
          → Code (parse body: status==ok? each dependency up?)
          → IF (body healthy AND latency < threshold?)
              → healthy → Google Sheets (log OK)
              → degraded → Slack #perf (200 but body unhealthy)
      → no:
          → HTTP Request (retry once after wait)  ← double-verify
          → IF (still failing?) → Slack #incidents (service down)
  → Google Sheets (append result + parsed body state)

1. Check readiness, not just liveness

Liveness tells you the process is running. Readiness tells you it can serve traffic. They diverge exactly when it matters: a slow boot, a dependency reconnecting, a queue backed up. Hit /healthz/readiness for the question that affects users, and treat a not-ready response as degraded rather than dead, because it usually clears on its own and shouldn't page someone at 3am the way a hard down should.

2. Assert the body, not the status

This is the gap. Parse the JSON and check what it actually says.

// Code node after the health HTTP Request
const body = $json.body ?? {};
const code = $json.statusCode ?? 0;
const healthy =
  code >= 200 && code < 300 &&
  body.status === "ok" &&
  Object.values(body.dependencies ?? {}).every(d => d === "up");
return [{ json: { url: $json.url, code, healthy, body } }];

A 200 with db: "down" now reads as unhealthy, which is the whole reason to monitor an API instead of just a URL.

3. Double-verify before paging

Networks blip, and one failed request is noise more often than it's an outage. Borrow the pattern the better incumbents already use: on a failure, wait and retry once. Only page if the second check also fails. It costs a few seconds and removes most false positives.

4. Split degraded from down

A slow 200 and a 503 need different responses. A latency branch flags the slow-but-working service to a performance channel; a failed body or status goes to incidents. On-call should know at a glance whether to roll back or just keep an eye on it.

5. Log for real availability

Every check, healthy or not, writes a row: endpoint, status, body state, latency, timestamp. That's how you compute actual availability, including the degraded windows a status-code-only monitor never recorded. The history also feeds a recovery notice when the body returns to healthy.

Implementation Patterns

Pattern 1 — Body assertion as a first-class check. Treat the parsed body the same way you treat the status code: a gate that has to pass. The AI Ops Watchtower template pings endpoints every 15 minutes, logs health history to Google Sheets, and sends AI-written alerts the moment a service goes down, with the body check wired in alongside the status check.

IF (status 2xx) → IF (body.status == ok) → healthy ; else → degraded alert

Pattern 2 — Two endpoints, one workflow. Check liveness and readiness in the same run and label which one failed. The alert says "ready check failing" or "process down," not just "unhealthy."

Pattern 3 — Recovery off stored state. Track the last state per endpoint and fire a resolved message when the body goes green again. A monitor that never closes the loop gets muted.

Where This Breaks, and What to Watch

A health endpoint is only as honest as whoever wrote it. Plenty of /health routes return a hardcoded {"status":"ok"} that never actually checks the database, the cache, or the queue behind them. Asserting that body gives you false confidence, not coverage. Before you trust the check, confirm the endpoint genuinely probes its dependencies, or push for a readiness route that does. A green light wired to nothing is worse than no light, because it stops people looking.

Watch the interval against the work, too. A 5-minute check is fine for most services, but if the readiness endpoint itself is slow (it reconnects to a dependency on every call, say) a tight schedule can stack runs or add load to a service that's already struggling. The n8n Schedule Trigger drops a new run if the previous one is still executing, so a slow health endpoint plus a short interval quietly means fewer checks than you think. Match the interval to how fast the endpoint actually responds.

The body assertion has a maintenance cost worth naming. When the API team adds a new dependency to the health response, your assertion needs to know about it, or it'll either ignore a new failure mode or trip on an unexpected field. Keep the expected shape in the Sheet alongside the endpoint, treat it as a contract you update when the API changes, and review it when a service ships a major version. It's a small bit of upkeep that's easy to forget until the check goes stale.

n8n Nodes You'll Use Most

Getting Started

1. Add a Schedule Trigger at a 5-minute interval.
2. Load endpoints and their expected body shape from a Code node.
3. Hit /healthz/readiness with an HTTP Request, continue-on-fail.
4. Assert the body in a Code node, not just the status code.
5. Double-verify failures with a wait-and-retry before paging.
6. Split degraded from down, log every result to Google Sheets.
7. Start from a template rather than rebuilding the body assertion by hand.

For page-level checks rather than API bodies, n8n uptime monitoring with Slack alerts covers the same debounce and recovery discipline, and automating DevOps workflows with n8n connects health checks to paging and incident updates. When a body check fails, the AI Ops Guard template can carry the remediation note.