Scanning offline.

Doors are basements, car parks, beaches and back roads. Signal is not guaranteed, so the scanner is built not to need it.

What the scanner knows before the signal goes

When you pick a terminal and a schedule, the scanner loads a manifest: the guest list for that schedule, held on the device.

The manifest is deliberately thin. It carries what the door needs to make a decision, the guest, their ticket's schedule validity, and whether they have already been checked in, and nothing it does not, no phone numbers, no payment details, no registration answers. A phone left on a table at a festival should not be a data breach.

That local copy is what lets the scanner keep making correct decisions with no connection: it can still tell you this code belongs to this event, this ticket is not valid for this session, and this person already came through.

What happens to a scan when the connection drops

Nothing stops. The scan is accepted, the guest is told they are in, and the check-in goes into the scan queue on that device.

When the connection returns, the queue drains to the server automatically and the attendance records land. You do not have to do anything, and you do not have to stay on the page waiting.

The queue panel shows how many scans are waiting. Past a hundred you get a soft warning banner. There is no hard cap and the scanner keeps queueing past it, because a queue that refuses new scans at a busy door is worse than a long queue.

Connection states

The scanner shows one of four states:

Online. Scans are reaching the server as they happen.

Reconnecting. The connection is unreliable and the scanner is retrying. Scans queue meanwhile.

Offline. No connection. Scans queue locally against the manifest.

Sign-in required. The session has expired. Scanning still works and still queues, but nothing can sync until someone signs in again on that device. The scanner says so plainly and offers the prompt.

What offline cannot do

Two things need honest expectations.

Duplicate detection across devices. While offline, a device knows about check-ins in its own manifest and its own queue. If the same ticket is scanned on two different offline phones at two different doors, both accept it, and you get two attendance records when the queues drain. Online, the second scan is refused.

Guests who registered after the manifest loaded. Someone who registers on their phone while standing in the queue will not be in a manifest that was loaded an hour earlier. Refresh the scanner to pull a fresh manifest, or check them in from the door desk once you have signal.

Practical advice for a venue with no signal

• Open the scanner on every device before you leave the last place with a decent connection, and pick the terminal and schedule then.
• Keep one device somewhere with a signal if there is one, so at least part of the door syncs continuously.
• Do not close the tab mid-shift. The queue lives on the device, and closing the page mid-drain is the one way to make life harder for yourself.
• After the event, open each device once with a connection and confirm its queue is empty before you pack up.