Dashboard not loading

Hi, is anyone else unable to load their dashboard? I’m just getting an endless load screen. Have tried 3 different browsers, cleared cache, restarted, logged out/in, problem persists.

Update: dashboard finally loaded but when I try to open an app I get “Could not load network resources”. On retry - “this site cannot be reached”.

Going on 1 hour and still unable to access the dashboard. Switching from wifi to mobile data didn’t make any difference. This is where I’m trying to go https://go.glideapps.com/

@Dan76 - I was able to replicate this just now in Chrome. However, I was able to resolve it by clearing all glide-related cookies and then re-loading. I can see that you tried clearing your cache, but just doing that normally leaves cookies intact. So give that a go.

Here are the steps I followed:

I’m back in! Thanks Darren. I tried with Firefox a couple of times and had no luck, but clearing those cookies in Chrome has worked.

1 Like

Unfortunately the problem is back and is now worse. Redoing the delete cookies process does not help. Additionally, cannot open any apps from any mobile device.
Trying to create a support ticket but it requires a url generated from the dashboard - which I can’t access! Is my Google login corrupted somehow?

Could be a temporary network issue somewhere along the route between you and glide.


Do you have another computer that you can try the builder from?

Can you share one of your App URL’s so that we can test? Even if it’s private, we can at least tell you if the login screen loads - if that would help.

You guys are so nice. Seriously going the extra step!


Have tried on all 3 of the computers in this house, and an iPad to boot

I’d say Jeff is probably right. Network related. Try a ping and/or trace to go.glideapps.com in a console and see what you get.

Alright, have hustled my way into the dashboard, grabbed a url: https://indigo-house-9846.glideapp.io/
While the dashboard is back, I’m still unable to open any apps. There have been fleeting moments throughout the day where the dashboard has opened but I expect to it glitch again at some point until it’s properly resolved.

Make sure you’re pinging with https instead of http. Really shouldn’t need to specify the http anyway.

1 Like

@Dan76 I’m curious, you don’t happen to be in Australia or NZ do you? If so you’re not alone

1 Like

Yeah I’m in Australia :grimacing:


Try with this syntax:

ping go.glideapps.com


If you have the same problem with all devices (PC/phones) in the same house, you problem might be associated to your ISP. Try to switch your internet provider for a while and test again. I suffered this issue months ago and I noticed that this issue was caused by Google, they blocked my public IP for unknown reasons and Glide servers were involved.


1 Like

If we’re into doing a bit of self-diagnosis, I thoroughly recommend a tool called MTR.

I’m not sure if it’s available for Windows, but it is available for both MacOS and Linux. It basically combines ping and traceroute to help you quickly identify where there might be dropped packets or high latency between two network nodes. It also has a report mode, which is really useful.

Here is what a typical run looks like:

dino:~ darren$ sudo mtr go.glideapps.com -r -c10 -y2
Start: 2022-07-11T00:31:57+0800
HOST: dino                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. SG               0.0%    10    9.9   4.7   2.9   9.9   2.3
  2. SG             0.0%    10    6.1   4.7   3.5   7.1   1.4
  3. SG              0.0%    10    3.8  11.4   3.2  39.1  13.6
  4. SG             0.0%    10   72.0  12.7   3.4  72.0  21.1
  5. SG              0.0%    10    6.4  10.9   2.7  43.3  12.9
  6. ??? ???                      100.0    10    0.0   0.0   0.0   0.0   0.0
  7. ??? ???                      100.0    10    0.0   0.0   0.0   0.0   0.0
  8. US             0.0%    10    4.5  10.4   4.0  35.2  10.6
  9. US              0.0%    10    3.9   4.0   3.2   5.8   0.9

That output tells me immediately that there is a problem at hop 6, with 100% packet loss.
I can identify the ISP at hop 5 using whois:

dino:~ darren$ whois | grep netname
netname:        STARHUBINTERNET-SG

So if that packet loss was actually causing problems for me now (it isn’t), I’d be complaining to StarHub :slight_smile:

1 Like

Thanks guys. I seem to be back in now, everything is working :+1:

1 Like