Guide · 4 min read

Why does our app say "check your wifi" when the wifi is fine?

Usually because the app is guessing. A request that never comes back looks exactly like a dead connection. Here is how I found the real cause for a shop whose tablets kept 'losing wifi', and the three questions to ask your own developer.

Last updated

fast request, same second
76 ms
fast request, same second
stuck request gave up
12 s
stuck request gave up
both fixes shipped
Same day
both fixes shipped
On this page

If your app says “check your connection” while every other website loads fine, the wifi is probably not the problem. The app is guessing. A request that never comes back looks exactly like a dead connection, so the app blames the network.

I know this because a client of mine, a coatings shop, ran into it early on.

What was happening?

The crew uses tablets on the shop floor to log jobs. Every so often the tablets would stop sending anything for a few minutes at a time. The message on screen said the tablet couldn’t reach the server. So everyone did the sensible thing. They restarted the router, moved closer to it, and switched to cellular.

None of it helped, because none of it was the problem.

How did I find the real cause?

I added a small report the tablet could send after a bad stretch. The first one came in on August 10, and one line in it settled it:

Time to answer, same tablet, same second

Load settings76 ms
Load the job board12,000 ms, gave up
From the tablet's report on August 10. One request flew through, the other hung.

Same tablet, same wifi, same second. One request flew through and the other hung. That can’t be the network. The network doesn’t pick favourites.

So what was it?

Think of a single checkout lane at a grocery store. My server sent every request to the shop’s database through one lane, one at a time, so we wouldn’t go over the database’s speed limit. That part was fine.

The problem was that the lane had no rule for a customer who never finishes. When one call to the database hung, everyone behind it waited. Every tablet. Meanwhile the tablets kept asking again every 10 seconds, so the line only got longer.

The settings request was fast because it came from a saved copy and never joined the line.

TABLETS WAITING Tablet 3 Tablet 2 Tablet 1 1 stuck call no time limit Database Before: one call hangs, every tablet behind it waits. After: 8-second limit, the line keeps moving.
One lane to the database. The fix wasn't a wider lane, it was a time limit.

What fixed it?

Two small changes, both shipped the same day:

  1. A time limit on every call. If the database hasn’t answered in 8 seconds, give up and let the next person through.
  2. No asking twice. A tablet doesn’t send a new request while its last one is still waiting.

Later we found a second version of the same shape on the tablet itself. One photo that failed to upload could hold up everything queued behind it. We fixed that the same way, and in late August the crew watched a stuck photo clear itself without anyone touching it.

What should you ask your own developer?

If your team keeps blaming the wifi, these three questions get to the answer fast:

  • “Can the error tell a dead network from a slow server?” If there is one message for both, you are guessing too.
  • “Does every outside call have a time limit?” One call with no limit can freeze everything.
  • “If one item fails, does it hold up the rest?” It should only block itself.

None of this is expensive to fix. It is usually a day, not a rebuild. The hard part is being willing to stop blaming the router.

If this sounds like your shop, see what fixes like this cost or try the demo of a shop-floor app.

Book a 20-Minute Call