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.