We break it on purpose, and we publish what happened.

Every KDS says it works offline. This page is the test results, run on every release, including the runs that failed.

Try it

Set the network state

Internet up Internet down, local network up Everything down

Everything is running. New orders arrive from your cloud POS and from your local network, and reporting is current.

2 Smash burger

no onion

add bacon

1 Fries

1 Chicken sandwich

1 Slaw

Allergen: peanut

3 Wings

hot

1 Ranch

1 Cheeseburger

2 Onion rings

1 Cobb salad

dressing on side

1 Iced tea

Now pull the plug.

Drop the network and keep bumping. Nothing stops. Watch the queue fill, then reconnect and watch it drain, oldest first.

Live — try it Offline and back

Connected Nothing queued

Bumps reach the server as they happen.

Timers run at 4× speed.

no onion

add bacon

0/2 made

Allergen: peanut

0/2 made

hot

0/2 made

Timers run at 4× speed.

The network control above is live. Set it to anything you like, keep bumping, and watch the queue fill and then drain oldest-first when you reconnect: the rail accepts a bump without asking the network for permission, which is the architecture described below. Tab · Enter · Space · →

How it works

The tablet is in charge, not the server.

Most kitchen displays are a window onto a server. The tablet asks a computer somewhere what to show, and draws it. When the connection drops, the window has nothing to show.

Ours is the other way around. The tablet keeps its own copy of every order. It draws from that copy, so the connection is not in the path between an order and your cook’s eyes. When the connection comes back, the tablet and the cloud compare notes and settle any difference.

Every bump, strike, and hold you make while offline is recorded and sent up when the connection returns. Once, not twice. That last part is the hard part, and it is why the same piece of code runs on the tablet and on the server, so the two cannot disagree about what happened.

What we test, every release.

These are the tests we run on every release. No results are published yet; the first published results land at launch, and a failure appears here as a failure, with the date and what we changed.
Test	Last run	Result
Network cut for 30 minutes under load	pending	pending
Router rebooted mid-service	pending	pending
App force-quit and restarted	pending	pending
POS outage, then a flood of replayed orders	pending	pending
500 orders on one screen	pending	pending

These are the tests we run on every release. No results are published yet; the first published results land at launch, and a failure appears here as a failure, with the date and what we changed.

Network cut for 30 minutes under load

Last run: pending
Result: pending

Router rebooted mid-service

Last run: pending
Result: pending

App force-quit and restarted

Last run: pending
Result: pending

POS outage, then a flood of replayed orders

Last run: pending
Result: pending

500 orders on one screen

Last run: pending
Result: pending

When a test fails, it goes on this page as a failure, with the date and what we changed. A page that only ever shows green is marketing. This is not supposed to be marketing.

See pricing