Max duration

max_duration bounds one invocation, including its response stream or WebSocket connection. Default 30 seconds, ceiling 8 hours.

max_duration is the longest a single invocation may run before Gigadrive Network cuts it off. One invocation means one HTTP request together with the response body it streams, or one WebSocket connection from handshake to close.

Setting it

version: 4

functions:
  api/index.js:
    max_duration: 60
  api/export.js:
    max_duration: 900

Setting	Value
Default	30 seconds
Minimum	1 second
Maximum	28800 seconds (8 hours)

The value is resolved from the Function that actually serves the request, so two Functions in the same deployment can hold different deadlines.

What it does not bound

The deadline applies to the invocation, never to the environment running it. When a request finishes, the environment stays and serves the next one. The platform may pause it, resume it, or retire it on its own schedule, and none of that is governed by max_duration.

Raising max_duration therefore does not keep a Function warm, and lowering it does not shorten a cold start.

Timeouts

A timeout mid-stream cannot be a 504

Once your Function has sent its response status and headers, the status line is committed. If the deadline then expires while the body is still being written, the body stream is errored instead. The client sees a truncated response with a 200, not an error status. Bound long streams inside your own code if a partial body would be worse than no body.

When the deadline expires before any response headers are sent, the request is aborted and the client gets a branded 504 page carrying EDGE_FUNCTION_TIMEOUT.

The deadline is also enforced inside the Function for handler-style code. A fetch export that overruns receives an abort signal there, so it can clean up rather than being cut off at the edge with no warning.

WebSockets

A WebSocket connection is one invocation, so max_duration is what closes it. The platform applies an absolute ceiling of 4 hours on top, which means the effective lifetime is whichever of the two is shorter. A connection that exchanges no bytes in either direction for 15 minutes is closed regardless. WebSockets covers the rest of the connection lifecycle.