Gateway timeout / unable to deploy error


I have a very large form and cannot find a way to decrease the amount of information that gets loaded immediately. This form is going to be used offline out in the field, so we have to have all of the sections accessible at once. I am able to deploy it every once in awhile by refreshing the page a bunch of times and clearing the browser cache, but otherwise it’s been a major hassle.

This issue started last week after some of my coworkers pulled the .xls form I had been working on and added their own sections, then reuploaded it. The form became slow at that point but still loaded within a reasonable time. Now, though, it takes 15+ minutes to load and I can deploy it maybe once per day.

The deploy error we get is:

unable to deploy

if this problem persists, contact

please check your connection and try again.


Mozilla: “Loading Error: Gateway timeout.”
Chrome: "Unchecked runtime.lastError: The message port closed before a response was received."x75
Edge & IE: “ is not responding due to a long-running script.”

We have tried deploying this from several different computers and different browsers in different states and different high speed connection types, yet all of us have the same problem – it’s not an internet connectivity problem. The form times out before it can fully load, and I can’t find any fixes or troubleshooting online.

Is there a way to reduce the amount of javascript that immediately loads? Refresh the connection to kobotoolbox before it times out? Or, maybe, load one section at a time? Any suggestions are appreciated!

Hi @tnkai,

Welcome to the community! Would suggest you to try out validating your xlsform with This helps in identifying your syntax error within your xlsform.

Hello, I have done that before each deploy - there are no syntax errors. The only warnings have to do with ODK & naming conventions for Google Sheets that don’t accept underscores (the default assignation for kobo), neither of which I am using for the form.

I would suggest going back one week and reload the XLS Form that was working well and rebuild from there, testing frequently. I imagine that someone introduced a logical error.

1 Like

I went through each of the ~5,200 lines of the xls file and found no errors other than some duplicate select_one names. I updated those and added options for them on the choices tab. I’ve done all of the standard troubleshooting, none of it helps.

Just confirming whether you actually tried working of a previous version of XLS that worked as suggested by @jblackman. If not then maybe you should do so.

It would also be important to show which errors are you exactly seeing.


I included my errors in the very first post, because I had already spent a significant amount of time troubleshooting the issues and decided to reach out for ideas in case someone else had experienced this and found a workaround.

As I said above, I went through each row to check for errors. And yes, I went back and looked at older versions and timed all versions up to the largest:

  1. The deploy process works fine until about 1,500 rows, where it slows down but is still usable.

  2. At about 2,100 rows, the deploy process and the preview page starts to take ~5 minutes each to load.

  3. At 3,500 rows, deploy takes about 8 mins, the preview takes about 7 minutes with intermittently choosing to continue the slow loading script,

  4. At 4,300 rows, deploy becomes so unreliable that it can only be uploaded maybe once or twice per day, after refreshing the browser and cache all day, and, apparently, catching the server at a low traffic moment. Preview takes 9 or so minutes to load.

  5. At 5,000+ rows, deploy is impossible, preview loads after 10+ minutes.

Hi @tnkai, thanks for the detailed troubleshooting you’ve done. Are the bulk of the ~5,200 rows in the choices sheet, and, if so, have you tried

If you’re willing to share your form with the development team for further troubleshooting, please send it to me via private message on this forum.

1 Like

No, the “choices” sheet only has around 1,600 lines. I’ll send you one of the most recent versions of the form, where the “survey” sheet has over 7,000 lines and includes most of the info we need to use.

1 Like

@tnkai, I know we have a separate private conversation going on now, but for the public’s benefit, what are you using to fill out this form? Enketo, Collect, or something else? I’m curious to know how the client performs with a form this large.

1 Like

For the most part, we are using the multiple submission link and working from a browser. Some of our reviewers have to use the form where there is no wifi access, so I had them pre-load the forms before they went out of range. They field tested it using laptops and they said it worked well enough (barring some other issues with printing, shared forms, etc.)

I have tested it with Collect - it loads fine, but the questions are hard to keep track of and come across strangely because of how I currently have the questions set up for the grid theme. It’s also quite difficult to navigate through so many sections on a small device.