Sentry is structurally blind to Node.js delivery-level wedges where the server produces a response (fast 200 in http.server transaction) but the TCP connection stalls before the client receives it. Server-side: no slow transaction, no error. Client-side: page never renders so no pageload transaction fires, no client error captured. The gap exists because Sentry instruments at the application layer (SvelteKit resolve / Express handler) not the transport layer. Duration-biased sampling catches slow resolve() but not fast-resolve-slow-delivery.
Add a per-minute server heartbeat log line emitting process metrics (RSS, event-loop latency, active TCP sockets via process.getActiveResourcesInfo()). A wedged instance shows up as either a heartbeat gap (process frozen) or monotonic active_sockets growth (connection leak). Complement with an external uptime monitor (Sentry Uptime, Pingdom, etc.) that probes from outside the infrastructure — this catches the user-perspective failure that in-process Sentry cannot see. The heartbeat approach is more attributable (shows the trend leading to the wedge); the external monitor is more decisive (binary up/down from the user's POV).