If the internet goes down or the cloud is unreachable

Connections break: the provider, the router, a thunderstorm, an outage at the operator. The venue does not close because of it — guests are standing at the counter. Below is exactly what keeps working, what does not, and what the shift should do.

Tell two failures apart, because they behave differently:

The POS deliberately does not try to guess the cause: any network error means "work locally, write to the queue".

What you need to get started#

Before the connection drops, open the POS on the device and in the browser you will use. Load the menu and prices, check the shift and test printing through the bridge on that PC.

Extended autonomy is in beta. If your version has the “Working without the internet” indicator, open “Set up the till for offline work” → “Set up the till”. Preparation needs internet access, a signed-in account and staff PINs. Look for “The till is ready to work offline”, not just cached data. Resolve any “not ready” items before disconnecting.

How data syncs#

The menu, prices, staff and settings are saved as local snapshots after successful cloud loads. Without a connection, the POS uses what it already has: a price changed on another device will not reach this POS until fresh data is loaded. Sales and cash operations travel in a separate queue in the other direction — from the POS to the cloud.

On a prepared POS, open “Working without the internet” → “Set up the till for offline work”. “Update access” renews permission to work offline and the staff grant data; it is not a full price-sync button. The indicator shows the cashier and an “offline until …” date. When it expires, it shows “Offline access expired — connect to the internet”.

In “Shifts and register”, check the age of menu, staff, sales settings and inventory snapshots. The POS sends a health summary to the cloud at most once a minute when it changes, or every 10 minutes when unchanged, while online, signed in and prepared. This reports queues and sync status; it is not a catalogue refresh schedule. When the POS is offline, the cloud only knows its last reported state.

The bridge on your PC and the local network#

Without an available bridge, the web POS continues using its own local storage if prepared. Sending print jobs to another PC through the cloud needs internet access.

What keeps working#

The regular web POS with its browser queue. This path stores records on the device; its limits are listed below. Extended beta autonomy uses a separate grant and journal:

• an order is rung up and goes into the order queue (it lives on the POS for 24 hours);
• receipts and the cash shift get their own operation queue (opening a shift, pay-ins and pay-outs, a receipt, a refund, closing a shift). Every operation carries a client-side idempotency key, so syncing never duplicates anything;
• a shift opened offline gets a temporary number and keeps working: the gate "no payment without an open shift" applies offline too, computed from the local cache;
• the menu, prices, tables and reference data are read from the browser's local cache — they got there while the connection was alive;
• reloading the page does not throw you to the login screen: the POS opens in a "degraded session" from a local snapshot and reconnects itself once the network is back.

Printing. The receipt, the kitchen ticket and the label are printed by the bridge installed on the same computer: the POS talks to it over the machine's local address — no internet needed.

The fiscal receipt. If the fiscal printer is connected to the same computer, the receipt is issued through the bridge over that same local channel: the fiscal drive accumulates documents and the fiscal data operator catches up once the connection appears. At a location set to Russia, also monitor the fiscal register and delivery to the fiscal data operator.

The login screen. As long as the browser holds a recent session (the window is 7 days), the cashier signs in and works; sending the accumulated data will still require real authorization once the connection is back.

What does not work without a connection#

• The web kitchen display (KDS). Tickets reach it through the cloud; without the internet new orders will not get to the kitchen — they will travel there once the connection is back. Meanwhile the kitchen works from printed tickets, if you have kitchen printing set up, or from spoken orders.
• The bank terminal. Card payment requires authorization at the bank — it will not go through offline. Take cash.
• Online payment by the guest (card on the storefront, paying the bill at the table, paying at the kiosk) — it needs access to the payment provider.
• Other browsers in the venue. The web POS does not participate in LAN exchange. Native apps have a separate beta local-network mode described above.
• The cloud X report. It needs a connection. In beta autonomy, “Shifts and register” shows a provisional report from the local journal; final cloud reconciliation waits for delivery of the operations.
• Admin sections that compute on the server — Orders, Finance, Statistics, Inventory, Staff. They read the cloud, and offline they show at best the last thing they managed to read.
• The expo screen, the queue display, the kiosk — cloud surfaces as well.

What staff should do#

1. Keep ringing up. As soon as the connection drops, an amber "offline" banner and an "N not sent" chip appear in the POS. Check the payment and printing outcome: a queued record alone does not confirm that a receipt came out.
2. Print the guest's receipt as usual. Local printing needs no internet, but the bridge and printer must be working.
3. Stay on the same device and the same browser. The queue lives on this computer: you cannot move to a second tablet and "sync it from there".
4. Do not clear the browser cache, do not sign out, do not open the POS in private mode — that erases unsent orders and receipts.
5. You may reload the page. The queue survives a reload and a browser restart.
6. Do not ring up the same order twice "just in case": the system protects against duplicates on sync, but two different orders will honestly be counted as two.
7. Do not accept cards — the terminal cannot authorize offline. Take cash, or issue an invoice if the guest prefers to pay later.
8. A red "N not delivered" banner means some records did not go through even after the connection returned (they expired or the server refused). That is a reason to call the manager, not to hide the banner.

What happens when the connection returns#

Syncing starts on its own — on the "network is back" event, when you return to the tab, and on a timer.

• The "N not sent" chip goes down and disappears. Orders appear in the Orders section and on the kitchen display, receipts get numbers, stock is written off according to recipe cards.
• There will be no duplicates. Every order carries a client-side identifier and every POS operation an idempotency key; the server recognizes a repeat and does not apply it twice.
• The offline shift is replaced by the real one. The temporary shift number is rewritten to the real one in every receipt and movement still waiting in the queue.
• The Z report is produced for a shift closed offline.
• Nothing is deleted silently. Records that could not be delivered (a day expired, or the server returned an unrecoverable error) go into a separate "not delivered" list (kept for 7 days, up to 100 records) and are shown in a red banner that can be dismissed manually.

These limits apply to the regular browser queue. In beta autonomy, check the separate journal status and grant expiry.

Order is preserved: the queue is sent sequentially, and on temporary server errors it retries with a growing pause.

Updating the bridge and apps#

An update may restart the bridge or app. Choose a quiet moment and check pending operations first: there is no automatic wait for the cash shift to close.

For an APK, Android may ask you to allow installation of unknown apps for this particular app. If updating fails, save the error message for support.

If you need support#

The bridge and apps automatically send reports about recorded errors. This helps diagnosis but does not guarantee delivery of every failure: a report cannot arrive immediately without a connection, and the bridge only keeps its report queue until the process restarts.

Open “Support” in the sidebar and copy the support code. Send it with the location name, error time, bridge or app version, message text and the step where work stopped. A screenshot of the banner and the number of pending operations are useful. The page address with #sc= also carries context for support. Do not clear POS data to collect diagnostics. See How to get help.

Limitations#

• Cloud functions need a connection. POS autonomy and beta exchange between native devices do not replace the cloud admin panel, online payments or bank authorisation.
• The queue is tied to the device and the browser. It lives in that specific browser's storage: another computer, another browser or private mode will not see it.
• The regular browser queue lives 24 hours for orders and POS operations. More than a day without a connection and records move to the "not delivered" list instead of quietly disappearing.
• Fallback access from the cached session lasts seven days. After that, without a valid autonomy grant, a normal online sign-in is required.
• The local report is provisional. It does not confirm that the cloud has accepted every operation.
• Guest-facing surfaces (storefront, kiosk) keep a queue for one hour only — they are meant for a short mobile-network gap on the guest's side, not for working without the internet.
• Android/Windows. Do not apply browser queue limits and capabilities to apps: they have their own journals. Extended autonomy depends on the released version and grant; LAN remains in beta.
• An end-to-end "pull the cable" run on a live fiscal printer has not been done yet. The POS offline mode is covered by code and automated tests (including an "in-session offline" e2e test), while a check on real hardware by the owner is on the plan — we say this plainly instead of presenting it as done.

Troubleshooting#

FAQ#

Does a location need a separate server?#

No separate location server is required. The web POS keeps its own browser queue, while the bridge on the same PC can store local snapshots and a command journal. In the beta native-app LAN, the lead node is selected automatically from available devices at the location. These are different paths; browser tills do not join the native LAN.

How should I prepare the bridge PC for the working day?#

For a stationary PC, we recommend wired networking and a UPS; check power to the router and equipment too. Keep the bridge PC on and awake while other workplaces use its fiscal device or printer. Before service, test printing and offline preparation while the internet is available.

Does a backup printer replace a backup kitchen server?#

No. A kitchen station’s “Backup printer” is an alternative print destination, not a backup for web KDS or the cloud. Configure it using Kitchen printing and check the printer and bridge are reachable. Without the internet, web KDS receives no new orders; use local printing that you tested beforehand.

Does the POS work without the internet?#

Yes: it rings up orders, prints receipts and fiscalizes them through the bridge on the same computer. Everything that has to reach the cloud accumulates in a queue on the device and is sent automatically.

Will data be lost?#

The queue survives a page reload and a browser restart, and whatever could not be delivered lands in a visible "not delivered" list instead of vanishing. Clearing or damaging storage can lose records; do not postpone investigating pending operations.

Can 54-FZ receipts be issued offline?#

Yes, if the fiscal printer is connected to the same computer as the bridge: the fiscal drive accumulates documents and passes them to the fiscal data operator once the connection appears. Continuing also depends on the fiscal register and memory unit status; check hardware warnings.

Why does the kitchen display not work?#

The regular web KDS receives tickets through the cloud. Compatible native apps have a beta local-network mode. If it is not prepared, use printed kitchen tickets.

Can a guest open the menu while we have no internet?#

Yes — the storefront is served from a CDN and does not depend on your internet. An order placed by a guest will reach the cloud, but in the venue you will see it only after the connection is back.

What about card payments?#

Take cash: the bank terminal needs authorization at the bank.

How long can the POS hold out without a connection?#

The regular browser queue lasts 24 hours; fallback access from the cached session lasts seven days. In beta autonomy, check the grant expiry and POS readiness; fiscal or other hardware conditions may stop work earlier.

Related articles#

• POS — orders, payments, service modes and the "Working without the internet" section
• Cash shift and Z report — opening, movements, X and Z reports
• Cenaly Hardware Bridge — the bridge on the POS computer, printers and fiscal printers
• Kitchen printing — tickets by station when the kitchen display is unavailable
• Kitchen display (KDS) — how tickets reach the kitchen
• First day: cafe, restaurant, canteen — what to switch on right away