Miget’s edge proxies apply a small set of timeouts to every HTTP request. These limits keep connections healthy, free up resources from leaks, and define a clear contract for how long a request can run before the proxy intervenes. The same limits apply across all regions.

​
Request Duration: 15 Minutes

Each HTTP request has a 15-minute budget. The clock starts when Miget’s proxy begins reading your request and ends when your application has finished sending the response. If either side takes longer than 15 minutes to complete, the proxy closes the connection. This budget is generous enough to cover most long-running web workloads:
  • Streaming responses: Server-sent events (SSE) and chunked transfer encoding.
  • Long polling: Clients holding a connection open while waiting for new data.
  • Token-by-token responses: LLM endpoints that stream output as it is generated.
  • Slow database queries: Single requests that take minutes to compute.
  • git push: Pushes to the builder, including silent periods while the build runs.
For workloads that legitimately exceed 15 minutes (bulk imports, batch processing, video encoding), run them as background jobs rather than blocking an HTTP request. Trigger the job from a fast HTTP endpoint and let the client poll for completion or receive a webhook.

​
Idle Keep-Alive: 5 Minutes

Once a connection is established, it can remain open and idle (with no data in flight) for up to 5 minutes before Miget closes it. After that, the next request from the client opens a fresh connection automatically. If your client maintains long-lived HTTP connections, such as connection pools or SDK clients that reuse sockets, set the client’s keep-alive interval below 5 minutes. A 60 to 90 second probe is typical and ensures the client refreshes the connection before the proxy times it out.

​
Request Headers

Request headers must arrive promptly after the connection opens. Connections that send headers very slowly are closed before they reach the application. This protects every Miget app from slow-header (Slowloris) attacks without any configuration on your side.

​
WebSockets

WebSocket connections are governed by the 5-minute idle keep-alive, not by the 15-minute request budget. As long as data (including ping or pong frames) flows in either direction at least once every 5 minutes, the connection stays open indefinitely. If your application or client goes idle for longer than 5 minutes, send a ping frame at a shorter interval, typically every 60 to 120 seconds, to keep the connection alive.

​
Request Body Uploads

Uploading a request body counts toward the 15-minute request budget. The limit applies to the entire request, not to individual write operations, so a slow client uploading a large file at low bandwidth will be cut off if the upload takes longer than 15 minutes. For large or unbounded uploads, use a presigned URL to upload directly to object storage from the client, then notify your application via a separate, fast HTTP request. This pattern avoids streaming the full payload through your application’s request path and removes the 15-minute ceiling.

​
What Happens at the Limit

When Miget closes a connection at the timeout, your application sees the socket close mid-request or mid-response. The client sees the response cut off, or, if no response had started, no response at all. Build clear application-level error handling for this case so users see a friendly message rather than a hung request.
Plan for graceful timeouts in your applicationCap individual operations in your application below the 15-minute platform limit and handle timeouts cleanly. A user-facing error returned by your code is always better than an abruptly closed connection.