Can two offline devices avoid checking the same person in twice?

Not reliably — two devices with no connection cannot know what the other has scanned. What matters is what happens afterwards: ask the vendor to show a duplicate created while both devices were offline, and what reconciliation reports once they sync. A rule you can see beats an assurance that it cannot happen.

What else stops working when the network is down?

Card payments for walk-ups, badge printing if it routes over the venue network, live dashboards, and anything shared between devices such as session capacity or re-entry rules. Offline check-in solves the queue at the door; it does not make the rest of the stack local.

How do you test offline check-in before the event?

Put a device in airplane mode the evening before and scan three real tickets: a valid one, one already checked in, and one for another event. Then restore the network and confirm the queue uploads on its own and that check-in times show when people actually arrived rather than when the upload happened.

What happens to check-in when the venue Wi-Fi fails?

By Donghui Qian (Milo)Updated 19 September 20265 min read

Short answer

It depends on whether the attendee list was downloaded to each device before doors opened. If it was, the device validates scans on its own, stores each check-in with the time it happened, and uploads the queue when the connection returns; if every scan is checked against a server, the queue stops when the network does.

Summarise with

Venue networks fail in the same twenty minutes every time: doors open, four hundred phones join the guest SSID at once, and the desk that was scanning in two seconds starts spinning. It is the most predictable failure in the whole event and the least planned for.

This guide is about what the desk does next. It is written for any check-in tool, ours included.

“Works offline” means four different things

Vendors use the phrase for any subset of these four. Ask which ones, because the difference decides whether the queue moves.

Capability	What it means	Without it
The list is on the device	The attendee list was downloaded before doors opened	Nothing works offline at all — every scan is a network call
Scans validate locally	The device decides on its own whether this code is valid	Scanning appears to work and then fails at the end of the queue
Check-ins queue locally	Each check-in is stored with the time it happened, not the time it uploaded	Arrivals are lost, or all timestamped the moment the network returns
Sync is automatic	The queue uploads itself when the connection comes back	Someone has to remember to press something, on every device

A tool with the first two and not the last two will get you through the morning and lose the record of it.

It is usually not “the Wi-Fi is down”

Complete outages are rare. The realistic failures are worse, because everything looks connected:

Saturation. The access point is fine and serving four hundred devices. Packets get through eventually — after the person at the desk has given up.
Captive portals. The venue network needs a click-through that expires, so devices silently drop off mid-morning and rejoin as “connected, no internet”.
Mobile data in a hall. A basement, a concrete exhibition hall or a full auditorium can take 4G to nothing regardless of the bars shown.
A network that blocks what you need. Guest VLANs that allow browsing and block the ports or domains an app uses look identical to a broken app.
Power and time. Devices on their own battery since 07:00, and clocks that drift — which matters when the timestamps are the record.

This is why “the venue says the Wi-Fi is good” is not an answer. The question is what the desk does when it is not, and nobody has time to diagnose which of the five it was.

What still breaks when scanning does not

Offline check-in solves the queue. These four keep needing a network, and the plan has to say so out loud:

Payment at the door: Card terminals and on-the-spot registrations need a connection. Decide in advance whether walk-ups are taken on paper and processed later, or turned away.
Badge printing: If printing runs over the venue network rather than from the device, it stops when the network does. Test the path, not the printer.
Live numbers: Dashboards and the count someone is texting to the client are the first thing to go stale. Say so before the event, or the organiser thinks the room is empty.
Anything shared between devices: Two offline devices cannot know what the other scanned. Session capacity, re-entry rules and duplicate detection all depend on a network, and all degrade when there is not one.

That last row is a physical limit, not a product gap. Ask a vendor what reconciliation does when the same person was checked in on two devices while both were offline — the honest answer is a rule, not a denial that it can happen.

The pre-flight, the evening before

Download the list on every device, then confirm the count on screen matches the registration report.
Rehearse in airplane mode. Scan three real tickets with the network off: one valid, one already checked in, one for a different event. Watch what the screen says each time.
Check the clocks. Same time zone, automatic time on, on every device.
Charge everything, and bring the cables. A device that dies at 09:10 is an outage with extra steps.
Write the staff line. Decide now what someone says when the screen shows “already checked in”, and who they call over.

When the network comes back

The recovery is where the record is made or lost. Three things to verify in the tool before you rely on it:

Check-ins keep the time they happened, not the time they uploaded — otherwise your arrival curve is a spike at 09:47.
The upload is automatic and visible: staff can see how many are still queued on that device.
Conflicts surface as something a human can resolve, rather than being silently overwritten by whichever device synced last.

Ask for this demo, not for the feature list

Every platform will say it supports offline check-in. Fifteen minutes settles it — ask the vendor to do exactly this, on their own device, in front of you:

Put the device in airplane mode. Scan a valid ticket, a duplicate, and an unknown code, and show what each one looks like on screen.
Register a walk-up while still offline, and say what happens to their payment.
Turn the network back on and show the queue draining, then show the check-in times in the report.
Do the same on a second device that was also offline, with one attendee scanned on both, and show what the report says afterwards.

Run it past every vendor on the list, ours included. This is the one part of the demo that is impossible to fake with a slide.

Frequently asked questions

It depends on whether the attendee list was downloaded to the device before doors opened. If it was, the device can validate a scan on its own and store the check-in with the time it happened, then upload the queue when the connection returns. If the tool checks every scan against a server, the queue stops the moment the network does.