Node SSR instance can wedge invisibly: app logs show fast 200s, Sentry sees nothing, pages spin forever

Incident: a SvelteKit (adapter-node) SSR service on Render served a page that spun in the browser for many minutes. Server request logs showed the same URL completing with status 200 in 400-1900ms throughout. No 500s, no error logs, no Sentry events. A deploy (instance replacement) fixed it instantly.

Why every detector missed it:

1. SvelteKit handle hooks measure resolve() completion, not delivery. A hook that times await resolve(event) logs when the Response object is produced. Socket-level delivery (adapter writing the body to the client) happens after, and static assets (sirv) are served before hooks run at all. A connection-level wedge is invisible to app-level request logging.

2. Sentry is structurally blind to this failure class. Server side: responses were fast 200s, so no slow transaction and no error. Client side: the page never executed JS, so no pageload transaction and no client error is ever sent. Pageload transactions only report on completion - a page that never loads produces zero telemetry.

3. No ongoing health check = no auto-healing. The service had no healthCheckPath configured; the platform only TCP-checks at deploy. A wedged-but-listening process holds the port open indefinitely. Render specifically: with healthCheckPath set, an instance failing checks for 15s stops receiving traffic and is restarted at 60s.

The Node mechanism that fits the evidence: fd/socket exhaustion or accept-queue stalls make NEW connections hang while EXISTING proxy keep-alive connections keep being served - which is exactly why some requests kept logging 200 while a specific user's fresh connections spun. Also relevant: Node's default server.keepAliveTimeout is 5s; behind a proxy that reuses idle upstream connections longer, the proxy writes to sockets Node already closed (ECONNRESET/502/stalls). Render docs recommend keepAliveTimeout/headersTimeout of 120s for Node services with intermittent resets.

Fixes that close the gap:

• HTTP health check route inside the app framework (traverses TCP accept -> HTTP parse -> router -> framework resolve, the exact path that wedges) + platform healthCheckPath for auto-restart.
• Periodic heartbeat log line (event-loop p99 via perf_hooks monitorEventLoopDelay, rss, active socket count via process.getActiveResourcesInfo) so the next wedge is attributable: heartbeat gap = event loop died; monotonic socket growth = leak.
• Raise keepAliveTimeout above the proxy idle window, headersTimeout slightly above that.

Key diagnostic heuristic: fast 200s in app logs + user reports infinite spinner + nothing in Sentry = connection/delivery-level wedge. Check instance boot lines for age, restart the instance, and add health checks.