I have increased the query timeout on my self-hosted implementation by adding the following line to the docker.env file located at //root/retool/retool-onpremise:


I rebooted the container and when I run 'docker-compose config' I can see following line under the db-ssh-connector, jobs-runner, and postgres sections of the output:


So it appears to me that the variable is being passed.

I increased the "Timeout after ms" value to 240,000ms in the "Advanced" tab on one of my queries that was timing out with the value set at 120,000ms. I closed the browser, cleared all cookies and logged back into my instance.

When I run the query it continues to timeout at 120 seconds (120,000ms).

What have I missed to get the query timeout extended?

Hey @gdtrafb!

For some context here would you mind sharing the version of Retool you're on and what type of resource you're using? Historically, some resources have had timeout settings separate from DBCONNECTOR_QUERY_TIMEOUT_MS though a lot has been done to have the variable apply more generally.

Also just want to confirm as a sanity check that the timeout settings on your database server allow for a 240 second timeout.

Aaand one last place to look is the ingress or load balancer in front of your Retool instance if you have one as it may have separate timeout settings as well :sweat_smile:

Let me know what you find?

Thanks for your help! I'm connecting to a Postgres database running on Postgres 12. The query I'm testing runs perfectly on Postgres in about 2:15 minutes.The Postgres statement-timeout setting for the user that Retool is connecting under is set to the default of 0 so querys are not time limited.

I'm running Retool v 2.99.6 hosted on an Ubuntu 22.04 server running on a Hyper-V VM. Both Postgres and the VM are running on the same LAN network in the same location. They are only a few feet apart from each other.

I'm using a pfsense firewall as our gateway router. There is no load balancer implemented on the router. It shouldn't matter even if there was as all the traffic is lan traffic and it would not hit the router as it's layer2. Lan traffic does get routed through a smart switch but I'm pretty sure that there is no type of traffic scheduler enabled on it, only vlans.

I have something else to add to this issue. This morning I logged back into my instance. Upon doing so I noticed that the "Timeout after ms" value on the query that I am testing had reverted back to the default of 120000. The value of 240,000, which I had entered yesterday, was over written once I logged off the instance.

I reentered the value of 240,000 and reran the query and it again timed out. I then logged off the instance and logged back in. The "Timeout after ms" value had again reverted back to 120,000. I have the same behavior on both Firefox and Edge.

I'm curious to see what, if any, errors are being returned particularly when you try and save the query with a new value. Can you check your browser's network tab to see if there are any requests failing? It might also help to see your container logs.

Can you also try setting a timeout greater than 240s so we can check to see if the error message also reflects the value of DBCONNECTOR_QUERY_TIMEOUT_MS you've set?

Finally, if you wouldn't mind exporting your app, I'd be interested to see what your app JSON looks like right after you've set the query timeout to 240s, and then again when you reload it and it's back to 120s.

This is very odd behavior!