We have an internal setting for controlling the timeout for customers with specific needs.
We do not like enterprise features like that, but we do need to protect our resources. Open file descriptors can be exhausted if a lot of connections are left open on the same hosts.
Bandwidth is a different game. We have fairly large pipes on all our hosts, we should be able to handle bandwidth requirements for most apps, the pricing is pretty clear on that ![]()
The âenterpriseâ plan weâre thinking up concerns supports (via email, including a way to reach us faster during emergencies) and more relaxed limits for app instances (such as the timeout weâre talking about here, but also things like connection backlogs, concurrent TLS handshakes, etc.). Basically, dedicated resources for the proxy, as opposed to the current multitenant-only model.
These plans arenât ready yet! Just thinking about them.
Itâs 60 seconds.
Applies to both HTTP and raw TCP. Theyâre âidleâ timeouts. If no data is read or written within 60s, the connection is forcefully closed. It applies for both edge connections and connections we make to your app instances.
UDP is connection-less and doesnât require timeouts.