The Monitor Was Green Through the Whole Outage

The monitoring box was ticked. There was a /health endpoint, and there was an uptime monitor pointing at it, reporting green. On paper, operations was handled. Then I read the two pieces. The health endpoint’s entire body was return new Response("ok") — it answered 200 whether or not the database was alive. And the monitor was a scheduled function inside the same deployment it was watching, so if the app went down, the thing checking it went down with it. Both would report calm straight through a real outage. A monitor you can’t trust is worse than none, because it’s the reason nobody looks.

This is a representative audit — the exact pattern I hit over and over on apps built with Lovable, Bolt, v0, and Cursor. Names and paths are changed, but every finding below is real-shaped and drawn straight from the kind of report the launchworthy skill produces. Call the app roomboard: a SvelteKit app on self-hosted Postgres, health check present, monitor configured, about to go live.

Nothing here throws an error, and that’s the trap. Both failures are green-when-it-should-be-red, which is the one kind of failure a dashboard actively hides.

The finding: a health endpoint wired to nothing

A monitor reads a status code and nothing else. So the whole job of a health endpoint is to return a non-2xx when the app is actually unusable. roomboard’s returned 200 unconditionally:

// routes/health/+server.ts
export function GET() {
  return new Response("ok")     // proves the process is up. Nothing else.
}

This tells you the Node process is running and can serve a route. It cannot see a dead database, an expired third-party key, or a queue that stopped draining — the outages people actually have. It returns 200 straight through all of them.

The fix: touch the dependencies the app can’t work without, and let the status code carry the verdict.

// routes/health/+server.ts
import { json } from "@sveltejs/kit"
import { db } from "$lib/server/db"

export async function GET() {
  const checks: Record<string, boolean> = {}
  try {
    await db.query("SELECT 1")     // cheapest round trip that proves the DB answers
    checks.database = true
  } catch {
    checks.database = false
  }
  const healthy = Object.values(checks).every(Boolean)
  return json({ status: healthy ? "ok" : "degraded", checks },
    { status: healthy ? 200 : 503 })   // the status code is the signal
}

The second finding: the watcher lives inside the patient

The monitor was a scheduled job in the same project as the app. When the host, the region, the DNS record, the TLS certificate, or the deploy itself is what breaks, that job is down too — and reports nothing, which reads as silence, not as an outage.

The gap under both: nothing watches the critical path

Even a perfect uptime check is only the floor. The homepage can return 200 for weeks while signup throws on the insert, or the core booking action returns empty. A ping can’t see any of that.

The false alarm: “the dashboard is green, so we’re up”

This is the belief the whole setup was built to produce, and it’s the dangerous one.

The rest of the punch list

The false-green health check is the one that has to change before launch, because it’s actively lying. The rest is ranked so scope stays honest:

The shape: a monitor that lies is worse than no monitor, so it goes first; the rest is turning a green light into an actual safety net. Worst-first reads as “make the health check honest and the monitor external before launch, add the synthetic pass this week.”

Why this keeps happening

Monitoring gets faked without anyone meaning to fake it. Adding a /health route that returns “ok” and pointing something at it feels like monitoring — the box gets ticked, the dashboard goes green, and green is exactly the outcome you wanted to see, so nobody interrogates it. The failure only reveals itself during a real outage, which by definition hasn’t happened yet on a pre-launch app. AI builders generate the endpoint and the config that produce a green light; producing a light that can go red at the right moment is a different, invisible kind of work.

That’s the gap launchworthy exists to close. It plays bouncer at the door of production: it knows a static-200 health check wired to a monitor is an active false green, that a checker living inside the deployment can’t report the outage that took it down, and that uptime green says nothing about whether signup still writes a row — so it refuses to mark monitoring as passing on a dashboard it can’t verify, and hands you the honest health endpoint, the external monitor, and the synthetic check instead.

The endpoint answered. The monitor was green. The box was ticked. And every one of them would have stayed calm while the database was on fire.