It sounds like a network thing. They can have something set up that cuts the connection for whatever reason.
If that’s what is happening, changing host won’t make a difference(as you say it works everywhere else), but it never hurts to try? 
If the issue is in the network of the hospital can the app be hosted locally there? I guess it does not need to be used outside of the local network.
Yes Albin, network is important, but all the other websites works without a glitch! here! So this reflects back to the Xojo/XC. Network is network, but if other sites and apps can cope with it…
And to test even Xojo apps overall, from this forums “Deployed Web app examples”, I have tried a randomly a few examples to test theirs behaviour, and for example this
doesn’t disconnects, doesn’t give this timeout page.
That example seems to be a stand alone Xojo app, not a CGI like you have. That should not make a difference though.
Try creating a new blank web app in Xojo and deploy it to XC and see if it also stalls.
The same problem with my other webapp:
http://104.130.219.185/Activator-Dev/
It stops here exactly the same way. This is a very simple webapp, one page, without any file I/O feature. A simple code calculator. But it also stops here, from the same Xojo Cloud server.
I don’t really know what this is about, but the page incessantly asks if I want to share my location, and then a few more times.
Edit. Stays alive. If I click a button it gives me a nice error at the top that I can’t read because it is in a foreign language for me and is overlaid by the blasted request for my location.
Peter this other webapp was ONLY an example, Albin wanted to test a very simple app. This is a one of my old medical Vb6 software’s new online licensactivering code generator. The error message comes from the webapp itself, and means only that you wrote in bad code of course. The geolocation is also by default, this is business and we want to see, who install and activate a new software copy and where.
Ps: The language was hungarian.
UPDATE: the problem is NOT solved, but I managed to find an ugly workaround, which seems to be working flawlessly now! I noticed, that the “disconnections” are not permanent and in a few cases the webapp can revive from its frozen, disconnected state. So I have written a little demoapp, which looks for theese outages. And it was a big surprise to see, we can have huge interruptions in the web, between 10sec up to 4 minuter. BUT! If I load or refresh something in the browser, a news portal, etc, it triggers also a signal which “wake up” again the webconnenction. This is crazy, but this happens, I don’t know, it is intended or not. I have tested it all the day between my patients, and it is absolutely reproducable.
It is not so easy to talk with the IT department, so as a workaround I have created an invisible HTMLwiever in my webapp, which aims a non-existent www page, and with a timer I refresh it constantly (0.4 sec) in the background. This sounds crazy, and of course this is not a real solution, but works fine! The webapp works as a charm, no disconnections, no unplanned timeouts! The user experience and the screen is smooth, it doesn’t blink, runs without any pause.
Why non-existent www? I don’t want to trigger a DoS attack alarm anywhere, plus it loads faster to the 404 error message, you don’t have to load in the big data of a real site.
And as a “side effect”, with the webapp running, I can use the net also seemingly smoother, and now I understand, why had I small troubles with it.
(The question is now: what will the IT say, when they will measure a special new communication pattern from my room…)
Well, if it’s not a problem with the internet provider which is totally out of ITs control, then any IT/Network manager worth their salt will get this fixed for you rather quickly once they are made aware of it.