> ## Documentation Index > Fetch the complete documentation index at: https://docs.getcuemanager.com/llms.txt > Use this file to discover all available pages before exploring further. # Offline and real-time > How CueManager keeps working without internet and stays in sync across devices. 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. | Still available | Notes | | ------------------------------------ | ---------------------------------------------------------------------- | | The live floor and table statuses | As of the last time the device heard from the server | | Running sessions, scores, and timers | Including frames recorded on this device since the outage started | | Recording frame results | Queued and applied in order | | Session checkout | The bill is worked out on the device and confirmed by the server later | | The POS terminal and catalogue | Item prices come from the cached catalogue | | Open customer tabs | Adding charges and settling | | Member list | Profiles and playing history only — see the wallet limitation below | 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. | Chip | Meaning | | ----------------------- | ---------------------------------------------------------------- | | **Offline** | The API cannot be reached right now | | **N waiting to sync** | Work recorded on this device has not reached the server yet | | **Syncing N…** | The queue is being sent | | **N sync issues** | Something was rejected and needs a person to decide | | **N from another user** | Queued work belonging to a different login on this shared device | ## What happens when the connection returns 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. Three frames recorded offline are sent before the checkout composed after them, so the server bills the frames it should. Every queued write carries an operation ID. If a send is retried after an uncertain failure, the server recognises it and applies it once. 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: | Section | What it holds | | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Stock needs a recount** | Offline sales that took stock below zero. The sale went through — the shelf and the system now disagree, so count and correct. Acknowledge with **Counted** | | **Needs review** | Work the server rejected. Each row shows what it was, when it happened, and why it is stuck | | **Waiting to sync** | This user's queue, informational — nothing to do | | **Recorded by another user** | Queued work from a previous shift on a shared device. Read-only; it sends when that user signs in again | Rows in **Needs review** carry a state: | State | Meaning | | ------------ | --------------------------------------------------------------------------------------------------------- | | **Conflict** | The world changed. Only a person can decide whether the money still applies — never retried automatically | | **Failed** | The server refused it | | **Retrying** | A temporary server problem. The app will send this again by itself | | **Stale** | Unsent for more than 72 hours. The server may now refuse it | 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](/members/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. | Live across devices | Examples | | ------------------- | --------------------------------------------------------------------------------------------------------------------- | | Table statuses | A table turning Occupied when reception starts a session; new, renamed, or removed tables | | Sessions | Session started, frame recorded, session ended or cancelled, running timers and totals | | Snooker scoring | Every pot, foul, and frame end from the marker, including the public [spectator scoreboard](/sessions/snooker-marker) | | Cameras | A table camera going online or offline, and suspected frame-end alerts | This is what lets reception, the marker, and the manager's phone all show the same floor at once. See [Live floor](/tables/live-floor). ## Related The real-time view of every table. How an offline bill is quoted and confirmed. Deferring payment when the wallet is unavailable. Selling from the cached catalogue during an outage.