Cloud POS Offline Mode: Six Things to Test Before the Lunch Rush
At 12:10 on a Friday, the WAN link to one of your stores drops. About 40 seconds later the point-of-sale terminals show a yellow banner across the top of the screen: offline mode. The store manager glances at it and relaxes. "We have offline mode. We're fine."
The banner is where the question begins, not where it ends. Offline mode is a feature your POS vendor ships. Offline readiness is something you verify, and a test at one store only proves anything if every store is configured the same. Across a hundred locations, that assumption is the first thing to fail.
Cloud POS offline mode: what it covers and what it skips
Offline mode is not one thing. Two of the largest vendors ship it, and they ship it differently.
Toast keeps orders flowing and stores card payments, forwarding them when the connection returns, as long as background card processing was enabled (it is by default). Square works inside a defined session window instead: reconnect and upload within 24 hours, and never later than 72, with several payment types excluded outright. The details vary by vendor and by release, so test your own configuration.
Six offline gaps to test
Every one of these gaps gets worse at a hundred stores than at one. Each has a drill you can run this week. None of them need a vendor call, just a cable you're willing to pull.
Card payments: the clock and the liability
Accepting a card offline is not the same as approving one. Toast keeps cards running, but pre-authorization only works if the card was pre-authorized before the outage, and the merchant owns any declined, expired, or disputed transaction that comes back. Square accepts offline cards too, but they expire: reconnect within 24 hours, no later than 72, and each one is capped by a per-transaction limit you set.
Drill: pull the WAN, run every tender type, and write down who eats the loss on each one.
KDS routing: in-store tickets only, under conditions
Your kitchen keeps working, but only if the network is set up one very specific way. Toast's offline KDS needs UPnP multicast enabled on the router and at least one hardwired Toast device acting as the local hub, and that hub only talks to devices on its own subnet. Segment POS, management, and guest traffic into separate VLANs, which is standard practice, and you've quietly reduced the chance offline KDS works at all. On non-Toast hardware, Toast won't guarantee it.
Drill: pull the WAN at peak and fire a ticket from every station to every screen, including a router restart in the middle.
Online and third-party orders
An order from the internet can't reach a store that isn't on the internet. Toast takes online ordering down while a site is offline, and orders that do arrive need approval after reconnect unless auto-fire is on. Delivery partners need a manual backup protocol. Square holds online orders until the disruption is over. There's no local fix for this one. It's a procedure problem.
Drill: decide who disables each channel, and how fast that happens across a hundred stores.
Gift cards and loyalty
These fail in front of the guest. Toast can't sell or redeem gift cards offline, and loyalty points can't be earned or redeemed. Square's gift cards are unavailable offline, and points earned during the outage have to be linked back manually once you reconnect.
Drill: ring a gift card and a loyalty redemption with the WAN down, and write the counter script your staff will actually say.
Menu edits, 86ing, and price changes
The menu freezes the moment you go offline. Toast's Quick Edit is unavailable, which means you can't 86 an item or override a price. Menu updates can't push while a site is disconnected. Sell out of the special at 12:10 on a Friday and the wrong menu keeps taking orders.
Drill: sell out of one item mid-service and measure how long the stale menu stays live.
Close-out, shift review, and recovery
The worst gaps show up after the outage ends. Offline, Toast blocks closing checks, cash tip declarations, reconciliation, and clocking out, and reports exclude offline devices until they sync. Don't hit Capture, don't log out, don't uninstall, don't restart the router; each one can cost orders or payment data. Square doesn't support close-of-day reporting offline, and signing out or switching locations loses pending payments.
Drill: close a shift mid-outage, then reconcile after reconnect and see what's missing.
Where the platform makes a difference
Most of these gaps are procedure, not hardware. Two of them, the KDS and the payment path, are infrastructure, and that's where the platform you run matters.
Toast's offline KDS depends on one hardwired terminal acting as the hub, on one subnet, with multicast enabled. That's a single point of failure, in a back office, at the exact moment everything else is going down. A local compute cluster changes that. When the KDS and payment-path workloads run on a store cluster rather than on one device, continuity stops hanging on a single terminal surviving the outage. The cluster self-heals: if a node or its power fails, workloads restart on the healthy node instead of waiting for a truck roll.
Consistency is the other half. Profile-based management means every site is built from the same policy, so a drill result from one store is true at the next. New sites provision to the same known-good standard, and updates roll out progressively, with safeguards that stop a bad update before it reaches the rest of the fleet. TekkioHub gives you one view of every site, so "what's still down" is a query rather than a phone tree.
One honest limit: a local cluster doesn't make cloud services local. Gift cards, online ordering, and loyalty still live in the cloud, and no amount of local compute changes that. What it changes is the part of the store that has to keep working while the WAN is gone: the kitchen and the money.
Questions to pressure test
Bring these to your next ops and IT call.
- Does the backup link fail over before the POS declares itself offline?
- When did you last pull the WAN at peak, at every store?
- Are all stores on the same subnet layout?
- Who can disable online ordering fleet-wide, and how long does it take?
"Does our POS have an offline mode?" is the wrong question. The right one is: have we proven it, the same way, at every store? Offline readiness belongs to the operator, not the vendor.
October 01, 2025
September 01, 2025
October 13, 2025
Cloud POS Offline Mode: Six Things to Test Before the Lunch Rush
At 12:10 on a Friday, the WAN link to one of your stores drops. About 40 seconds later the point-of-sale terminals show a yellow banner across the top of the screen: offline mode. The store manager glances at it and relaxes. "We have offline mode. We're fine."
The banner is where the question begins, not where it ends. Offline mode is a feature your POS vendor ships. Offline readiness is something you verify, and a test at one store only proves anything if every store is configured the same. Across a hundred locations, that assumption is the first thing to fail.
Cloud POS offline mode: what it covers and what it skips
Offline mode is not one thing. Two of the largest vendors ship it, and they ship it differently.
Toast keeps orders flowing and stores card payments, forwarding them when the connection returns, as long as background card processing was enabled (it is by default). Square works inside a defined session window instead: reconnect and upload within 24 hours, and never later than 72, with several payment types excluded outright. The details vary by vendor and by release, so test your own configuration.
Six offline gaps to test
Every one of these gaps gets worse at a hundred stores than at one. Each has a drill you can run this week. None of them need a vendor call, just a cable you're willing to pull.
Card payments: the clock and the liability
Accepting a card offline is not the same as approving one. Toast keeps cards running, but pre-authorization only works if the card was pre-authorized before the outage, and the merchant owns any declined, expired, or disputed transaction that comes back. Square accepts offline cards too, but they expire: reconnect within 24 hours, no later than 72, and each one is capped by a per-transaction limit you set.
Drill: pull the WAN, run every tender type, and write down who eats the loss on each one.
KDS routing: in-store tickets only, under conditions
Your kitchen keeps working, but only if the network is set up one very specific way. Toast's offline KDS needs UPnP multicast enabled on the router and at least one hardwired Toast device acting as the local hub, and that hub only talks to devices on its own subnet. Segment POS, management, and guest traffic into separate VLANs, which is standard practice, and you've quietly reduced the chance offline KDS works at all. On non-Toast hardware, Toast won't guarantee it.
Drill: pull the WAN at peak and fire a ticket from every station to every screen, including a router restart in the middle.
Online and third-party orders
An order from the internet can't reach a store that isn't on the internet. Toast takes online ordering down while a site is offline, and orders that do arrive need approval after reconnect unless auto-fire is on. Delivery partners need a manual backup protocol. Square holds online orders until the disruption is over. There's no local fix for this one. It's a procedure problem.
Drill: decide who disables each channel, and how fast that happens across a hundred stores.
Gift cards and loyalty
These fail in front of the guest. Toast can't sell or redeem gift cards offline, and loyalty points can't be earned or redeemed. Square's gift cards are unavailable offline, and points earned during the outage have to be linked back manually once you reconnect.
Drill: ring a gift card and a loyalty redemption with the WAN down, and write the counter script your staff will actually say.
Menu edits, 86ing, and price changes
The menu freezes the moment you go offline. Toast's Quick Edit is unavailable, which means you can't 86 an item or override a price. Menu updates can't push while a site is disconnected. Sell out of the special at 12:10 on a Friday and the wrong menu keeps taking orders.
Drill: sell out of one item mid-service and measure how long the stale menu stays live.
Close-out, shift review, and recovery
The worst gaps show up after the outage ends. Offline, Toast blocks closing checks, cash tip declarations, reconciliation, and clocking out, and reports exclude offline devices until they sync. Don't hit Capture, don't log out, don't uninstall, don't restart the router; each one can cost orders or payment data. Square doesn't support close-of-day reporting offline, and signing out or switching locations loses pending payments.
Drill: close a shift mid-outage, then reconcile after reconnect and see what's missing.
Where the platform makes a difference
Most of these gaps are procedure, not hardware. Two of them, the KDS and the payment path, are infrastructure, and that's where the platform you run matters.
Toast's offline KDS depends on one hardwired terminal acting as the hub, on one subnet, with multicast enabled. That's a single point of failure, in a back office, at the exact moment everything else is going down. A local compute cluster changes that. When the KDS and payment-path workloads run on a store cluster rather than on one device, continuity stops hanging on a single terminal surviving the outage. The cluster self-heals: if a node or its power fails, workloads restart on the healthy node instead of waiting for a truck roll.
Consistency is the other half. Profile-based management means every site is built from the same policy, so a drill result from one store is true at the next. New sites provision to the same known-good standard, and updates roll out progressively, with safeguards that stop a bad update before it reaches the rest of the fleet. TekkioHub gives you one view of every site, so "what's still down" is a query rather than a phone tree.
One honest limit: a local cluster doesn't make cloud services local. Gift cards, online ordering, and loyalty still live in the cloud, and no amount of local compute changes that. What it changes is the part of the store that has to keep working while the WAN is gone: the kitchen and the money.
Questions to pressure test
Bring these to your next ops and IT call.
- Does the backup link fail over before the POS declares itself offline?
- When did you last pull the WAN at peak, at every store?
- Are all stores on the same subnet layout?
- Who can disable online ordering fleet-wide, and how long does it take?
"Does our POS have an offline mode?" is the wrong question. The right one is: have we proven it, the same way, at every store? Offline readiness belongs to the operator, not the vendor.
October 01, 2025
September 01, 2025
October 13, 2025