TL;DR: A festival network is rarely "down". It is connected, slow, and randomly dropping uploads, which is worse for a point-of-sale app than a clean outage. We ship a PWA POS that runs at events, and the things that hurt us were not the obvious ones:
navigator.onLine, service worker updates, Background Sync assumptions, and device clocks. This post walks through each one with the fixes we landed on.Key Takeaways
- Design for lie-fi, not offline. Measured stadium networks deliver a P90 time-to-first-byte of nearly 6 seconds on 5G while still reporting "connected".
navigator.onLineis a hint. Drive your offline state from request timeouts and a health probe.- Persist every sale to IndexedDB with an idempotency key before the UI says "paid". Replay against a server that owns the truth.
- Order transactions by server sequence, never by device time.
- Service workers on a tab that never closes need a different update strategy than a marketing site.
- Background Sync is missing on Safari and Firefox. Treat it as a bonus, not a plan.
- Safari can evict your storage after 7 days of no use. Installed home-screen apps are exempt.
The network at a festival is not "offline", it is lie-fi
The dominant failure mode at a crowded venue is a connection that looks fine and behaves terribly. The web.dev offline cookbook calls this "lie-fi": the radio is attached, the status bar shows bars, and every request crawls or dies (web.dev, Offline Cookbook). A binary online/offline model does not describe it.
The best public measurements we know of come from a July 2026 study at Notre Dame Stadium, which seats up to 77,622 people. On game day, P90 browsing time-to-first-byte was 5,983 ms on Verizon 5G NSA and 2,916 ms on AT&T. Note that those are P90 figures, not medians. WhatsApp image uploads failed 46.2% of the time on AT&T and 44.4% on Verizon. Page loads failed 24.7% to 36.6% of the time on cellular, versus 3.9% on the stadium's Wi-Fi 6 GHz network (arXiv:2607.16008).
The same study shows why Wi-Fi is the better rail when you can get it. Median TTFB on Wi-Fi 6 GHz was 573 ms during games, against 447 ms on non-game days, and median Wi-Fi latency was 19 ms. Median game-day downlink was 53 to 60.8 Mbps on both Wi-Fi and T-Mobile 5G SA (arXiv:2607.16008). The medians look healthy. The tails are where your card reader times out.
The demand curve explains the tails. At Super Bowl 60 in Levi's Stadium (70,823 fans), Verizon carried 40.32 TB, AT&T 24.4 TB, and T-Mobile around 11 TB, with Verizon averaging roughly 955 MB per connected customer. Verizon's total at Super Bowl 50 a decade earlier was 7 TB (Stadium Tech Report, AT&T newsroom). Festivals follow the same curve with worse infrastructure: Vodafone moved 225 TB at Glastonbury 2024, up 33% on 2023, over 10 temporary masts, including 258 GB uploaded during Coldplay's set alone (Vodafone UK). In 2025 traffic rose another roughly 25% on 11 masts (Computer Weekly).
Uplink matters more than you think for a POS. At the 2023 FIFA Women's World Cup, Optus saw over 29 TB across three stadiums, with about 25% of it uplink, and needed roughly 7,000 optimisation adjustments across more than 1,100 cells to keep it flowing (Ericsson Mobility Report). Every sale you post is uplink, competing with tens of thousands of people uploading video of the headliner.
When the network does fully drop, the public record is blunt. Reading Festival went cashless-only in 2021 and card machines at food stalls failed with no cash fallback, so stalls turned customers away (Berkshire Live). The Rogers outage in Canada on 8 July 2022 took Interac debit down nationwide, leaving food trucks at FVDED in the Park emptied out because only credit cards still worked, CBC reported (CBC). The Optus outage in Australia on 8 November 2023 lasted about 14 hours, hit more than 10 million people and around 400,000 businesses, and EFTPOS terminals on Optus SIMs could not process at all (Australian Government review). Download Festival's 2015 RFID system had top-ups not appearing and queues over 90 minutes, even though the operator said only about 1% of attendees were affected (Gigwise). One percent of a festival is still a very long queue.
Why navigator.onLine is the wrong signal
navigator.onLine tells you whether the device has a network interface attached. It does not tell you whether packets reach your API. MDN's own wording is that the property is "inherently unreliable" and should "only provide hints" (MDN, Navigator.onLine).
This bit us with what we now call lying Wi-Fi. Venue Wi-Fi behind a captive portal, or a temporary access point whose backhaul had died, reported online: true. Our app believed it, took the online path, and each sale hung for the full fetch timeout. Cashiers saw a spinner instead of a receipt and started re-tapping.
The fix is to derive connectivity from what actually matters: did a small request to your own API return in a sane time? The service worker cookbook notes that fetch inside a service worker has no automatic timeout, so a network-then-cache strategy with a deadline has to be built by hand (web.dev, Offline Cookbook). The same applies in the page.
type Connectivity = "online" | "degraded" | "offline";
async function probe(timeoutMs = 3000): Promise<Connectivity> {
const ctrl = new AbortController();
const timer = setTimeout(() => ctrl.abort(), timeoutMs);
const started = performance.now();
try {
const res = await fetch("/health", { cache: "no-store", signal: ctrl.signal });
if (!res.ok) return "degraded";
return performance.now() - started > 1500 ? "degraded" : "online";
} catch {
return "offline";
} finally {
clearTimeout(timer);
}
}
We run this on an interval, on online/offline events as a trigger to re-probe (not as truth), and after any request-level timeout. The three-state result drives the UI badge and, more importantly, whether new sales go straight to the queue without attempting the network first. A "degraded" state that queues immediately keeps the line moving.
The offline mutation queue: persist before success
The rule that keeps money safe is simple to state: a sale is not "done" on the device until it is durably written to IndexedDB with an idempotency key. Only then does the UI show success. Network delivery is a separate, retried step.
Most offline-first tutorials stop at caching reads. Payments are the hard part, and the core problem is double-application: the server applied the charge, the response was lost on the way back, and the client retries. Stripe's API documents the pattern we copy. The client sends an Idempotency-Key header; the server stores the first response status and body, including 500s, and replays that stored response for any retry with the same key. Stripe recommends UUID v4 keys, prunes them after at least 24 hours, and returns an error if the same key arrives with different parameters (Stripe, Idempotent requests).
Why CRDTs are wrong for balances
It is tempting to model a cashless wallet as a CRDT counter and let devices merge. CRDTs guarantee convergence for commutative operations (crdt.tech). A wallet balance is not commutative in the way that matters: "balance must not go below zero" is a constraint that depends on order. Two stalls each selling a 10 unit item to a wallet holding 15 units will both succeed offline and converge to minus 5. The result converges, and it is wrong.
So the server is authoritative. Each device replays its queue in order; the server applies or rejects each entry exactly once and returns the same answer on every retry. The device then reconciles its local view to whatever the server decided.
interface QueuedSale {
idempotencyKey: string; // UUID v4, generated once per sale
localSeq: number; // device-local ordering only
createdAtDevice: number; // display hint, never for ordering
payload: SalePayload;
attempts: number;
state: "pending" | "applied" | "rejected";
}
async function replay(store: SaleStore, api: SaleApi) {
for (const sale of await store.pending()) {
const res = await api.post(sale.payload, {
headers: { "Idempotency-Key": sale.idempotencyKey },
});
if (res.status >= 500) { await store.bump(sale, "pending"); break; }
await store.settle(sale, res.ok ? "applied" : "rejected", res.body);
}
}
Two details matter. A 5xx stops the loop and leaves the entry pending so order is preserved. A 4xx settles the entry as rejected, because Stripe-style servers return the same 4xx on every retry and looping on it wastes the shift.
Clock skew: server sequence numbers, not device time
Never order transactions by device time. Phones and rugged tablets at a festival have user-settable clocks, drift without NTP, and cross time zones in vans. NTPv4 exists precisely because clocks disagree (RFC 5905), and an unattended tablet in a field is not running a disciplined NTP client.
Several popular offline-sync write-ups present last-write-wins on client timestamps as safe. For a notes app, maybe. For a ledger, a device five minutes fast will have its later sales applied before another device's earlier ones, and a refund can land "before" the sale it refunds.
Our rule: the server assigns a monotonic sequence number when it applies a queued sale, and every downstream view (balance, reports, refunds) orders by that. createdAtDevice in the queue entry above is stored for the receipt and for debugging, nothing else.
Service worker traps on a tab that never closes
A POS tab opens at 10 am and closes when the bar shuts. That single fact breaks the assumptions most service worker guides make.
The update deadlock
The service worker lifecycle keeps exactly one version active per scope. A new worker sits in "waiting" until every client of the old one is gone (web.dev, Service worker lifecycle). A kiosk tab that never closes means the waiting worker never activates. Devices ran the old build for the rest of the event.
Forced skipWaiting drops precache
The obvious escape is skipWaiting(). The lifecycle docs are clear that this means the new worker serves fetches for pages loaded by the old one (web.dev, Service worker lifecycle). In our case the new worker's precache manifest did not contain the chunks the running page was lazily loading, so mid-shift a route change fetched a hashed file that no longer existed. Lazy imports failed. The cure: prompt-to-reload between shifts using the Workbox pattern (Chrome, Handling SW updates), and never force activation while a session is live.
Never revalidate the app shell offline
Our navigation handler once tried network-first for the shell with a cache fallback. Under lie-fi the network branch eventually rejected, the respondWith promise rejected, and the browser showed its own error page. The tab was now unrecoverable without connectivity. The shell is precached; serve it from cache on navigation and revalidate only on an explicit, online update check.
Queue your telemetry too
We instrumented offline failures by postMessage from the worker to the page. The sessions we most wanted to see were the ones where no page was listening: the shell had failed, or the tab had been killed. Telemetry about offline failures must go into the same durable queue as the sales, and replay the same way.
clients.matchAll can be empty during install
During install and early activation, clients.matchAll() returned nothing for us even though a tab was open. Any code that assumes "there is a page, tell it something" needs a guard and a fallback that persists state for the next page to pick up.
Background Sync is not a strategy
Background Sync lets a service worker replay requests once connectivity returns, even with the page closed. It is only available to about 76.73% of global users: Chrome 49+, Edge 79+, and Samsung Internet 5+, with no support in Firefox or Safari on macOS or iOS (caniuse). MDN lists it as limited availability and not Baseline (MDN). A festival fleet of iPads gets none of it.
The Workbox plugin's fallback semantics are worth reading twice. Failed requests are stored in IndexedDB; without Background Sync the queue is replayed only when the service worker starts. The plugin retries only thrown network errors, not 4xx or 5xx responses. And the DevTools "offline" checkbox does not affect service worker fetches, so your offline test may not be testing what you think (Chrome, workbox-background-sync).
Our position: own the queue in application code as shown above, replay from the page on every reconnect and on every app start, and treat Background Sync as an opportunistic extra on browsers that have it.
| Browser | Background Sync | Best-effort storage quota |
|---|---|---|
| Chrome / Edge | Yes (Chrome 49+, Edge 79+) | Up to 80% of disk per browser, 60% per origin |
| Samsung Internet | Yes (5+) | Chromium-based; follows Chrome limits |
| Firefox | No | 50% of disk, 2 GB per eTLD+1 group |
| Safari (macOS / iOS) | No | About 1 GB, then prompts in 200 MB steps |
Sources: caniuse, web.dev, Storage for the web.
Storage quotas and Safari's 7-day eviction
Your queue lives in IndexedDB, so its durability is only as good as the browser's storage policy. Chrome allows up to 80% of disk per browser and 60% per origin; Firefox allows 50% of disk with a 2 GB cap per eTLD+1 group; Safari allows around 1 GB before prompting the user in 200 MB increments. All of it is best-effort by default and subject to LRU eviction when the disk is low (web.dev, Storage for the web).
Safari adds a time bomb. WebKit caps script-writable storage at 7 days of Safari use without user interaction with the site; after that, IndexedDB and friends can be wiped. Home-screen web apps are exempt (WebKit blog). A tablet configured two weeks before the gates open, then left in a box, can arrive with an empty queue store and no cached shell. Install the PWA to the home screen, request persistent storage, and verify both on the morning of the event.
Before your next event: a checklist
- Run a 3 second timeout probe against your own API; do not trust
navigator.onLinefor anything beyond a re-probe trigger. - Write every sale to IndexedDB with a UUID v4 idempotency key before the UI shows success.
- Make the server store and replay the first response per key, including 500s, and reject reuse with different parameters.
- Stop replay on 5xx, settle on 4xx, and preserve queue order.
- Assign server sequence numbers on apply; never sort money by device time.
- Serve the app shell from precache on navigation; never let
respondWithreject offline. - Use prompt-to-reload between shifts; never call
skipWaiting()while a session is live. - Queue telemetry with the sales; assume no page is listening.
- Install to home screen on iOS, request persistent storage, and confirm the cache is warm on event morning.
- Test with a real captive portal and a throttled uplink, not only the DevTools offline checkbox.
Frequently asked questions
Can I skip the queue and just retry the fetch?
No. A retry without an idempotency key can double-charge when the server applied the first attempt and the response was lost. Persist the sale with a key first, then retry with the same key so the server replays its stored response (Stripe).
Does Background Sync work on iPads?
No. Safari on iOS and macOS does not implement the Background Sync API, nor does Firefox (caniuse). On those browsers, a Workbox queue replays only when the service worker starts, so trigger replay from the page on reconnect and on app launch.
Is venue Wi-Fi better than cellular for a POS?
Measured at Notre Dame Stadium, yes: page-load failures were 3.9% on Wi-Fi 6 GHz versus 24.7% to 36.6% on cellular, with a median Wi-Fi TTFB of 573 ms during games (arXiv:2607.16008). But venue Wi-Fi is also the source of lying-Wi-Fi captive portals, so the probe still has to decide.
Conclusion
The festival network is not a wall you hit; it is a swamp you wade through with the status bar insisting everything is fine. The engineering response is to stop asking the browser whether you are online and start asking your own API, to treat every sale as a durable, idempotent, server-ordered fact, and to run your service worker with the humility a day-long kiosk tab demands. None of this requires exotic infrastructure. It requires deciding, before the gates open, that "connected" is not the same as "working".
Written by the engineering team at CHI, who build ticketing and cashless payment tools for live events.
