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.
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 queue that can't quietly lose your day
Every 30 seconds
Changes queue on the device and push automatically while online, and immediately on reconnect — you don't press anything.
Backoff 1 min → 1 hour
Per-item retry, backing off so a flaky link doesn't hammer the server or drain the tablet.
Parked after 10 tries
Anything the server permanently rejects is parked for review rather than blocking everything behind it in the queue.
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.
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.
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 tillBrowser
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 screenWhat to do when the power goes
Four steps. Print it and put it behind the till.
-
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".
-
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.
-
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.
-
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.
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.