Picture a kirtan hosted in a converted barn an hour outside cell coverage, or a sunrise meditation retreat where the lodge's wifi hasn't quite reached the check-in table. BrightStar's scanner is built for exactly these gatherings — events that ask for stillness and presence but happen in places connectivity forgets. This guide walks through how offline mode works, what it can and cannot verify while you're disconnected, and how everything reconciles once a signal comes back.
How does the scanner load ticket data before you lose signal?
The moment a scanner link is opened for the first time, BrightStar downloads everything it needs to keep working without internet: every ticket ID for the event and the attendee name attached to it. This is stored locally in the browser's IndexedDB storage — roughly 50KB for every 1,000 tickets, a small enough footprint that even a modest phone handles it without strain. Because this caching happens on first access, it's worth opening the scanner link at least once while you still have a connection, well before doors open, so the download is already finished by the time you're standing somewhere with no bars.
What can the scanner actually check when it's offline?
Once the cache is in place, an offline scan runs two checks: does this ticket ID exist in the local list at all, and has it already been marked scanned on this specific device. A clean result on both shows green for valid; a ticket already checked in on that device shows red for duplicate. What offline mode cannot do is ask the server whether the ticket has already been scanned somewhere else — that comparison only happens once connectivity returns, which is why the sync process and the conflict rules that follow matter as much as the scan itself.
What happens once the scanner reconnects?
When a scanner that's been working offline finds a signal again, BrightStar syncs it automatically, without anyone needing to tap anything:
- 1Scanner detects network availability
- 2Queued scans sent to server in a batch
- 3Server validates and records all scans
- 4Conflicts resolved through duplicate detection
- 5Updated ticket list pulled back to the cache
- 6Interface shows a Synced confirmation
- 7The whole process is automatic and transparent
How does BrightStar resolve conflicts when scans come back in?
Two situations come up often at events with patchy connectivity, and BrightStar has a defined answer for both. If two offline scanners check in the same ticket before either has synced, the first timestamp wins: whichever scan happened earliest is recorded as the valid check-in, and the later one is marked Already checked in once its device syncs. The other case is a ticket refunded while a scanner is offline — the scanner's cache doesn't know about the refund yet, so it may still show the ticket as valid at the door. Once that scanner syncs, though, the server rejects the scan and logs it as Scan attempted on invalid ticket, so there's a record even though the check-in itself doesn't stand. Neither situation can be caught by the device in the moment; both only resolve once it talks to the server again.