We've looked into this from our side and haven't found anything on the Railway platform that explains what you're seeing, so working it out means digging into your specific setup.

That's exactly what the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

These disconnections keep happening to us over time. The two requests above are examples of an ongoing reliability issue, and we would appreciate help identifying the underlying cause.

The 60.3s example does not establish a 60-second SSE limit. Railway's current limits distinguish 60 seconds between HTTP/1.1 requests from an active response: HTTP requests can run for 15 minutes while transferring data, with a 5-minute no-data limit. Your 7.3-second failure also needs a different explanation.

The later 200 cannot establish complete delivery to the webapp. I tested a local Node 24.18.0 fixture that closed only a proxy's downstream connection while continuing to read its origin: the client received 200, then UND_ERR_SOCKET, while the origin emitted finish normally. This demonstrates the ambiguity; it does not identify Railway/Fastly as the cause of your failures.

A useful next distinction is whether Frank's actual HTTP response closes before finishing. Attach this before writing headers in its existing Node HTTP/Express handler:

function observeResponse(req, res, emit = console.log) {
  const started = performance.now();
  const requestId = req.headers['x-railway-request-id'] ?? null;
  const record = (event) => emit(JSON.stringify({
    message: 'sse_response', event, requestId,
    at: new Date().toISOString(),
    elapsedMs: Math.round(performance.now() - started),
    headersSent: res.headersSent,
    writableEnded: res.writableEnded,
    writableFinished: res.writableFinished,
  }));
  res.once('finish', () => record('finish'));
  res.once('close', () => record('close'));
}
// At the start of the existing SSE handler:
observeResponse(req, res);

close with writableFinished: false records an unfinished origin response; it does not identify who initiated the closure. A normal finish means data was handed to the OS, not acknowledged by the final client, as Node documents.

On the webapp, record the last actual body-chunk read time, bytes received and nested error.cause codes alongside each request ID. Configured heartbeats don't establish when bytes reached that reader. Undici distinguishes UND_ERR_SOCKET from its own UND_ERR_BODY_TIMEOUT.

Pair those timestamps with Railway's @requestId:5wsVpqn9RhqcyGC_2h0iww and @requestId:E8LnQVsqTb6isXD42prcFg HTTP-log filters. Empty responseDetails is not an end-to-end delivery confirmation; the field is documented for application-failed-to-respond details. Railway support would still need to correlate the private edge connection records to determine the closing component. I don't have access to those records.

Chandan