I’m planning on using fly.io as a proxy that contacts multiple backend services (deployed elsewhere) that take relatively long to process data (~180-200s).
Looking at the fly.toml documentation, I don’t see HTTP request timeouts being mentioned anywhere. So, I’d like to ask: what’s the HTTP timeout on fly?
60 seconds without any data being sent or received will cause the connection to be closed.
We do offer a configurable timeout via the Pro plan (it’s $99/month for a few niceties) and the by emailing support to get the timeout changed.
So just to confirm, webhooks or streamed responses won’t timeout because they are constantly sending data right?
Correct. As long as they send something within 60 seconds of the last sent packet
Great. That makes sense.
Reposting here since its a more recent thread…
I have a long connection that sends gRPC keepalive packets every 30 seconds. However this connection is still being cut after 60s. Do gRPC keepalive packets count as non idle?
My org is eligible for the Scale plan. I think we just need to email support.
Hey @jerome is this still the case?
I’m looking at your plans and there isn’t a $99 Pro plan. Also no mention of the custom timeouts either.
Hmmm. Right 
If you have an email address for support for your org, you can probably ask for a timeout change. This is all I got for now 
If you can, would you share the details of what the timeout you need and your use case?
Sure. I have an audio encoding service running in Google Cloud Run that I want to migrate to Fly.
I think with 4 or 8 CPU cores 99% of encodings could be completed in less than 20s (heck probably less than 10s) but there might be a small minority that could take over a minute for long audio files.
Honestly, I’d need to do some tests to be certain if I need a longer timeout than 60s or not.
Edit:
So if I used something like GRPC to stream some bytes to notify of the FFMPEG progress… that would not count as a timeout, right? Would that be acceptable?
Sure, if you’re sending data at least once per 60s (ideally less than 60s so as to not cut it too close), then that should keep the connection alive.
Hi @jerome ,
is it also true for server sent events? looks like my sse stream is getting killed at the 60 seconds mark.
My use case is pretty simple, I’m streaming back data from the open ai chat completion, and these take more than 60 seconds sometimes.