6 days ago
My service receives webhook requests at POST /api/inngest that can legitimately
run for several minutes. They are being terminated at exactly 5 minutes.
HTTP logs (Time GMT-5, 2026-08-15), same service, two consecutive attempts:
13:56:48 POST /api/inngest 499 5m
14:02:05 POST /api/inngest 499 5m
The application process is not crashing. Deploy logs show it still executing
work at 14:05:45, more than 3 minutes after the second request was cut. Memory
stayed flat around 300 MB during the whole window, CPU was near idle, no
restarts, no redeploys, and the Request Error Rate graph stayed at 0.0%.
My question: this feedback thread, marked Completed, says the platform HTTP
timeout was raised from 5 to 15 minutes:
https://station.railway.com/feedback/increase-max-platform-timeout-beyond-5-m-9d15d4ee
Is that 15-minute timeout active for my service and region? The measured
behaviour is exactly 300 seconds. If the effective limit is still 5 minutes for
me, is there anything I need to change to get the 15 minutes?
I am also trying to determine which side is closing the connection. The 499
status suggests the downstream client closed it rather than the edge proxy
timing out. If you can see the reason recorded on your side for these two
requests, that would settle it.
Node.js 22, Express 5.
1 Replies
6 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 6 days ago
6 days ago
You must keep data flowing on the HTTP response. For a long-running Inngest webhook handler (POST /api/inngest):Start streaming / flushing early
Send response headers and at least some body data (or periodic keep-alive chunks) before the 5-minute mark.
Node.js / Express practical optionsUse streaming responses and periodically write something (even a space or heartbeat comment).
Ensure server.requestTimeout, headersTimeout, req.setTimeout, and res.setTimeout are raised well above 15 minutes (or set to 0).
If using the Inngest serve handler, check whether it supports (or can be configured for) progressive responses / checkpointing / heartbeats. Inngest has features (checkpointing, connect mode) specifically to keep connections alive on platforms with idle timeouts.
Better long-term patterns for InngestPrefer Inngest’s connect (persistent WebSocket-style) over pure HTTP serve when possible — WebSockets are exempt from the duration/inactivity limits.
Or make the webhook return quickly and do the real work via steps / background execution so the HTTP request itself stays short.