Skip to main content
Clubs lose connectivity, and a shift cannot stop when that happens. CueManager keeps the floor running from the device itself, queues everything staff record, and sends it as soon as the connection is back. This page covers what works offline, what happens on reconnect, and what updates live across devices.

​
What keeps working offline

When the API is unreachable, the app falls back to data already stored on the device. Reports, tournaments, staff administration, expenses, and the club’s own subscription pages need a live connection and are not cached.
Screens show what the device last confirmed with the server. Anything recorded on this device since then is shown as well, so a marker’s score never appears to jump backwards mid-outage.

​
The sync chip

A chip in the app header reports the device’s state and is the way into the sync page.

​
What happens when the connection returns

1

The queue drains automatically

As soon as the API is reachable again, queued work is sent without anyone asking. You can also force a round with Sync now on the Sync issues page.
2

Order is preserved per table and per tab

Three frames recorded offline are sent before the checkout composed after them, so the server bills the frames it should.
3

Nothing is billed twice

Every queued write carries an operation ID. If a send is retried after an uncertain failure, the server recognises it and applies it once.
4

Money is re-checked, not assumed

A checkout or settlement sends the total the device quoted. If the world moved while the device was offline — another till recorded frames, another device settled the tab — the server refuses rather than silently settling at a number nobody agreed to, and the record lands on the sync page for review.

​
The sync issues page

Anything that cannot be sent, and anything the server refused, appears on Sync issues. Nothing is ever discarded silently. Any signed-in user can open the page; it is not permission-gated. The page is grouped in the order things need attention: Rows in Needs review carry a state: Depending on the row, the actions are Retry, Discard, Review & confirm (re-price a parked checkout at the current total and send it), View settlement, Review sale, or Convert to tab charge — used when a frame was played but the session was already closed on another device, so the money is still collected from the right customer.
Discard deletes the only record of that work. If cash was taken for it, write the discrepancy down before closing the shift — the row cannot be recovered.
A row marked Retrying has not failed. Do not re-ring the sale at the till: the original will land on its own, and re-entering it books the same basket twice.

​
Member wallet credit is not available offline

Paying from a member’s prepaid wallet needs the server to check the balance, because another till may have spent it. While the device is offline, Credit (Member Wallet) is unavailable at checkout and the dialog says Member wallet unavailable offline. Take cash instead, or use Add to Tab and settle from the wallet once the connection is back. Wallet top-ups also require a connection. See Wallets and credit.

​
What updates in real time

While the device is online, changes appear on every other signed-in device within a second — no refreshing. This is what lets reception, the marker, and the manager’s phone all show the same floor at once. See Live floor.

Live floor

The real-time view of every table.

Checkout and payments

How an offline bill is quoted and confirmed.

Customer tabs

Deferring payment when the wallet is unavailable.

POS terminal

Selling from the cached catalogue during an outage.