Offline & load shedding

Stage 6 is a trading condition, not an outage

Aura's terminals hold their own database. Staff sign in, ring orders and take walk-in payments with no server in reach — every sale committed atomically and queued. When the power comes back the queue drains itself and you close the day normally.

Be precise about it

Exactly what works, and what doesn't

Plenty of software claims to be "offline-capable". Here is the honest split, so your team knows what to do at the moment the lights go out rather than discovering it then.

Works offline

Commits to the device immediately, syncs later.

  • Signing in with a PIN — staff PINs sync to every device, so load shedding never locks the team out
  • Ringing items and building an order — notes, seats, courses, quantities
  • Walk-in ring-and-pay sales not bound to a table or tab — committed atomically with correct numbering, stock depletion and loyalty points
  • Discounts, voids and comps — the manager-approval flow works; audit rows sync later
  • Seating tables and rearranging the floor plan
  • Checklists — viewing and ticking, with who and when recorded
  • The local menu, the cart and the customer display

Needs a connection

These are live server operations — two tills must not diverge on them.

  • Sending an order to the kitchen, and every KDS action
  • Billing or settling a table or tab; splits, moves and merges
  • Gift-card, house-account and store-credit tenders; refunds
  • 86'ing an item and logging wastage
  • Clocking out, the X-report and the Z-report
  • The Tabs list, order history, waitlist and reservations
  • First-time device setup — the initial download of your menu and staff
  • Guest QR ordering — the menu and the order live on the guest's own phone, which talks to the server directly. A standalone QR Ordering venue has no terminal, and so no offline path: see the note below
A no-sale still kicks the drawer open offline — it just isn't recorded until you're back.
How sync works

A queue that can't quietly lose your day

Push

Every 30 seconds

Changes queue on the device and push automatically while online, and immediately on reconnect — you don't press anything.

Retry

Backoff 1 min → 1 hour

Per-item retry, backing off so a flaky link doesn't hammer the server or drain the tablet.

Dead-letter

Parked after 10 tries

Anything the server permanently rejects is parked for review rather than blocking everything behind it in the queue.

Pull

Converges both ways

The app also pulls the latest menu, prices, staff, customers, tables and reservations, so every device ends up agreeing.

The sync badge in the top bar

One glance tells the manager whether the day is safe. It's always visible, on every terminal.

● SYNCED ● QUEUE 1–9 ● QUEUE 10+ / PARKED
Where your data lives

Pick the right device for a real till

Desktop — Windows, Mac, Linux

Persists its database at ~/.aura/aura.db. Restarting loses nothing. Can print, and can drive a second monitor as the customer display.

Real till

Android & iOS tablets

Stores its database in the app's private storage — a restart loses nothing. Android can print; iOS printing isn't available in this release.

Real till

Browser

Doesn't keep local data across a page reload. Use the web POS as a convenience screen — a manager checking reports, a spare lookup terminal — and keep desktops and tablets as your real tills. It also can't print, and won't pop the green "ready to run" banner.

Convenience screen
The playbook

What to do when the power goes

Four steps. Print it and put it behind the till.

  1. Before it happens: UPS the router and the receipt printer

    The terminals run on their own batteries. What they lose in an outage is the network — so the router and the printer are what need backup power, not the tablets. This one decision is the difference between "we kept trading" and "we wrote orders on paper".

  2. During: keep ringing, take walk-in sales

    PIN sign-in works. Ringing works. Ring-and-pay walk-in sales complete properly — numbered, stock depleted, loyalty accrued, journal generated on sync. Cash and card both work; the stored-value tenders don't.

  3. During: defer the server-bound work

    Hold table and tab billing, kitchen sends and the Z-report until the link is back. If you have a mobile hotspot, pointing the terminals at it restores all of that — the server connection is all they need.

  4. After: watch the badge, then close the day

    The queue drains automatically. Wait for the sync badge to read Synced, then run the Z-report to close. A persistent red badge means items were rejected — get a manager to look rather than closing over it.

Why sales survive a power cut mid-transaction. Every sale is committed atomically on the device and queued for sync in the same instant. There is no window in which a sale is half-recorded — either it happened or it didn't.
This is the terminal's story, not the guest's phone. Everything above applies to the Restaurant and Shop tills, which hold their own database. Guest QR Ordering is a web app on the guest's phone talking to the server, so it stops when the server is unreachable — and a standalone QR venue, which runs no till at all, stops with it. If you trade through load shedding on guest ordering alone, plan for a UPS and a backup line on the router, and talk to us about it before you sign.

Test it on your own schedule

In a demo we'll pull the network mid-service so you can watch what the terminal does — and what the queue does when it comes back.