What Happens to a Restaurant POS When the Internet Goes Down?

What may continue locally

Depending on the design, devices may continue opening tables, adding items and printing kitchen orders over the local network. This is different from a browser page that stops completely when it cannot reach the server.

What may still require the internet

Online card authorisation, cloud-only integrations, remote reporting and third-party delivery services may be unavailable. Payment terminals can have separate fallback rules set by the acquirer; the POS cannot override those rules.

Protect the kitchen flow

The restaurant should know whether kitchen printers communicate locally and how staff confirm that a ticket printed. Avoid repeatedly pressing Send during uncertainty, which can create duplicate preparation when connectivity returns.

Synchronisation after reconnection

Offline actions need stable identifiers and conflict rules. Test two devices editing different tables, reopening an order and reconnecting in a different sequence. Totals, item quantities and printed updates must remain consistent.

Create a staff procedure

Provide a one-page outage guide covering the indicator staff will see, allowed actions, payment handling, manual notes and who is contacted. Train the procedure during a quiet period and keep support details available offline.

Test regularly

Simulate a controlled internet interruption before go-live and after major updates. Keep the local network running while disconnecting the external link, complete several orders and compare the final cloud records after restoration.

Run a controlled service test

Use the intended tablets, printers and network. Open several tables from different devices, send new items and quantity updates, add modifiers, remove an item with permission, split a bill and reprint it. Interrupt the internet connection while keeping the local network active, continue ordering, reconnect and reconcile every order and total before approving go-live.

Check data, access and continuity

Confirm who owns the operational data, how authorised users export it, which roles can see financial or guest information, and how access is removed when a staff member leaves. Ask what happens during an outage and how backups or service recovery are handled. These controls are less visible than a dashboard, but they determine whether the system remains safe and usable over time.

Record the decision and ownership

Before committing, write down the agreed scope, included modules, channels, users, support route, data-export method, total first-year price and person responsible for each setup task. Keep the same document for go-live acceptance. A clear decision record prevents a capable system from being undermined by assumptions that were never configured, tested or assigned.

Review results after go-live

Set a review for 30 and 90 days after launch. Compare the original problems with evidence such as time saved, exception count, direct-booking completion, room-readiness visibility, order accuracy or reporting effort. Remove unnecessary steps, retrain unclear workflows and agree any next integration only after the core process is stable. Improvement should continue after the installation date.

This guide provides general operational information. Product scope, channel availability, pricing and implementation requirements should be confirmed for the individual property.