For the complete Netlify documentation index, see llms.txt. Markdown versions of any documentation page are available by appending .md to its URL. These limits apply to every server. Memory, CPU, and disk depend on the instance size you choose. For the responses visitors receive when a limit is reached, refer to Troubleshooting.
Instances
Section titled “Instances”If you have a credit-based Pro or Enterprise plan, a server can scale up to 3 running instances at a given moment. Netlify starts more instances as traffic grows, up to that number, and new requests then share the instances already running.
On a Free or Personal plan, a server can only have one running instance at a time.
Request concurrency
Section titled “Request concurrency”How many requests an instance handles at once depends on its instance size:
| Size | Requests at once |
|---|---|
small | 32 |
medium | 64 |
large | 128 |
If Netlify has already scaled up your server to the maximum instances allowed, and every instance is handling as many requests as it can, a new request waits briefly for one to free up. If none does, it gets a 429 Too Many Requests response.
A Server-Sent Events stream, or any other streamed response, counts as a request in progress until it ends, so each open stream takes up one of those requests. WebSocket connections are counted separately, as described in WebSocket connections.
WebSocket connections
Section titled “WebSocket connections”Open WebSocket connections don't count toward the requests an instance handles at once, so they don't reduce how many requests it can serve. They have a separate limit instead, of a couple of hundred per instance, which counts the instance's open WebSocket connections and its requests in progress together.
When an instance has no room for another WebSocket connection, new connections go to another instance, and Netlify starts more as needed, up to your server's instance limit. Ordinary requests don't depend on this limit, so an instance that's full of WebSocket connections still serves requests.
Request duration
Section titled “Request duration”A request can run for up to 30 minutes, or 2 hours on Pro, Business, and Enterprise plans. The time covers the whole request, from when it reaches your server until the response finishes, including a streamed response. A request that runs out of time is cut off.
This includes WebSocket and Server-Sent Events connections, which are closed when they reach the limit. Make your clients reconnect when a connection closes.
If you need to continue running work in the background after the response is sent, see Background Work. Background work is not limited by the request duration.
Response timeout
Section titled “Response timeout”Your server has 20 seconds to send the response's status and headers. If it hasn't sent them by then, the request fails with a 502 Bad Gateway response. Once they're sent, the rest of the response can take up to the request duration limit.
The 20 seconds include any time the request waits for a new instance to start, such as the first request to a branch deploy or a Deploy PreviewDeploy PreviewA type of deploy that lets you preview and share changes for feedback before they go live.. Your entry file and start hooks have to finish within that time, with room left for the response itself.
Inactivity
Section titled “Inactivity”An instance stops after 5 minutes without requests. The timer starts when the instance starts, and starts over every time a request finishes. An instance doesn't stop for inactivity while it has requests in progress, including open WebSocket and Server-Sent Events connections, or background work pending.
Instance lifetime
Section titled “Instance lifetime”An instance is replaced after running for 8 hours, even if it's busy. The time counts from when the instance started. A replaced instance shuts down like any other, and the next request goes to a new one.
Shutdown
Section titled “Shutdown”When an instance stops, requests and background work in progress get up to 90 seconds to finish. Your shutdown hooks start at the same time and get up to 115 seconds to run, so they have at least 25 seconds after that work ends.
Outbound connections
Section titled “Outbound connections”A connection your server opens to another service, such as a database, an API, or a message broker, is closed after 60 seconds without any data sent or received in either direction. A connection that keeps exchanging data stays open, however long it's been running.
TCP keepalive packets don't count as data, so they don't keep a connection open. To keep a quiet connection open, send something over it at least once every 60 seconds. For example, run SELECT 1 on a database connection that waits for LISTEN notifications. Otherwise, reconnect when the connection closes.
If you use a connection pool, set its idle timeout below 60 seconds, so the pool closes idle connections itself instead of handing out one that's already closed.
Reserved ports
Section titled “Reserved ports”The following ports are reserved for Netlify inside every instance, so your server can't listen on them:
53, for DNSDNSThe system that translates a domain name like yoursite.com into the address computers use to find your site.15000to15099
Listening on process.env.PORT always gives your server a free port.
Reserved paths
Section titled “Reserved paths”Paths under /.netlify/server/ are reserved for Netlify. Requests for them never reach your server, even if its path setting includes them.
Did you find this doc useful?
Your feedback helps us improve our docs.