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.

A scan that fails to send is retried on its own, and the wait between tries grows the longer the outage lasts, up to a minute. The queue panel says so for each one, "Retries in 12s", so a scan that is waiting never reads as a scan that was lost. A Retry now button is there if you would rather not wait out the delay, but nothing at the door depends on anyone pressing it.

A scan that fails mid-flight is retried under the same key it was captured with, so a reply that went missing on the way back cannot turn into a second check-in for the same guest.

Scanned, and synced

These are two different numbers and the queue panel keeps them apart. A bar across the top shows the proportions at a glance, and under it sits one chip per status that is actually present:

Status	What it means
Synced	On the server. The attendance record exists, so the scan is safe even if the device is closed.
Queued	Captured here and waiting its turn to send.
Retrying	A send did not get through. The scanner tries again on its own.
Rejected	The server refused it. Sending it again repeats the same answer, so someone has to look.
Waiting for sign-in	The session expired. Sign in again and these go back in line by themselves.

A status with nothing in it gets no chip, so a quiet queue stays quiet. The five always add up to everything the device has scanned, so a scan can never go missing between them. Press a chip, or hover it on a laptop, to get the same explanation on the device.

The two that need a person are Rejected and Waiting for sign-in. Everything else clears by itself.

The scan-queue button carries the not-yet-synced count as a badge, so you can read the gap without opening the panel. It turns red when one of those two has anything in it.

Past a hundred unsynced scans 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. Once the session is live again the held scans go back in line by themselves, whether you used the prompt or signed in on another tab.

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 reads every scan synced before you pack up.