Skip to content

Why the till says it is offline

The three link states, why wifi that looks fine can still read as a weak link, and what the till can and cannot do in each.

Updated 11 September 20263 minApplies to: Till, Back office, Help centre

The till does not trust the wifi icon

Your device can be perfectly associated with the venue wifi while nothing actually reaches us: the dongle is out of data, the ISP is down, or the hotel-style sign-in page has expired and is quietly intercepting every request. The browser calls all of that "online".

So the till decides for itself. Every so often — when the tab comes back to the foreground, when the device reports a link, after a request fails, and on its own timer — it asks our server one very small question and listens for the answer.

There are three possible verdicts.

Connected

The server answered recently. Everything works normally, the queue empties, and reserved bill numbers refill.

A server error still counts as connected, deliberately. If we answer at all — even badly — your device has reached us, and telling you that you are offline would send you to check a router that is working fine.

This is the state that used to be invisible, and it is the important one. The device has an interface, but our server is not answering it — or is answering with a sign-in page that is not ours, which is exactly what a captive portal looks like from here.

The till keeps trading. Bills print, sales are saved on the device, and the queue waits. What it will not do is claim everything is fine, because in this state nothing you ring is reaching us yet.

One failed answer is enough to say weak link; the till does not jump straight to offline over a single dropped packet.

Offline

Either the device reports no network at all, or two attempts in a row failed. The queue grows — that is what it is for — and the till keeps working from what it already has.

Getting back

You do not have to press anything. While the verdict is not "connected", the till keeps re-asking on a widening gap — a couple of seconds, then longer, up to about half a minute — and the moment the server answers, the state clears itself and the queue starts moving. Opening the sync sheet and syncing manually does the same thing sooner.

If it stays stuck, the usual causes in order of likelihood are: a captive portal that needs somebody to sign in again in a browser tab, a data pack that has run out, and a router that has an address but no route out.

  • Opening orders, adding items, notes and discounts
  • Sending kitchen orders
  • Printing bills and settling, as long as this till has reserved bill numbers left
  • Recalling held orders and viewing your menu and your customers

What needs a connection

  • Splitting a bill
  • Issuing a credit note — return numbers are not reserved on the device
  • Closing the day
  • Reserving more bill numbers
  • Anything that reads live data from the back office; those pages show a dated copy and say so

Nothing in that second list is lost by waiting. They are the actions where guessing would be worse than pausing.

Still stuck?

Beta