The venue wifi will drop. Not might — will, eventually, at an event large enough to matter. It happens when three hundred guests arrive in twenty minutes and every one of their phones latches onto the same access point, or when the building's network has a quiet wobble that nobody notices until your kiosk freezes mid-check-in with a queue watching. The question is not how to prevent it. The question is what the kiosk does in the thirty seconds after it happens.
A kiosk that simply stops is worse than no kiosk at all, because a guest has already committed to using it. They have walked up, started, and now they are stuck in public with people behind them. The whole promise of self-service evaporates in that moment unless the device was built to expect the outage.
The two ways a kiosk fails
When connectivity goes, a poorly designed kiosk fails in one of two visible ways, and both are avoidable.
The first is the spinner. The guest scans or taps, the screen shows a loading state, and nothing comes back because the request never reached the server. The guest waits, taps again, waits again, and eventually a steward has to intervene. Multiply that by a queue and the kiosk has become the bottleneck it was meant to remove.
The second is the false negative. The kiosk cannot reach the list, so it cannot confirm the guest, so it tells them it does not recognise their code. The guest is now standing in front of a machine that just told them, incorrectly, that they are not invited. That is a worse experience than a slow human, because the machine sounds certain.
The job of a kiosk during an outage is not to pretend nothing is wrong. It is to keep working on what it already knows, and to fail in a way that does not embarrass the guest.
What graceful degradation looks like
A kiosk that handles the drop well does a few specific things, none of them flashy.
- It holds the list locally. The guest list it needs to validate against is already on the device, so a passing network wobble does not stop it recognising a valid pass.
- It queues the writes. When it checks someone in, it records that locally and syncs it the moment the connection returns, rather than blocking the guest until the server acknowledges.
- It keeps the count. Even offline, the device knows who it has let through, so the running total stays useful and reconciles cleanly once it is back online.
- It tells the truth quietly. If something genuinely cannot be resolved offline, it routes the guest to a steward without announcing a fault to the whole queue.
This is the difference between a kiosk that depends on the network for every interaction and one that treats the network as a sync channel rather than a lifeline. We have written about this from the scanner's side in scanning attendees when the venue wifi drops, and the principle carries straight across to unattended kiosks: do the validation on the device, sync the result when you can.
How CheckInHub handles the gap
CheckInHub kiosks are built to keep checking people in through a network gap. The list is on the device, check-ins are recorded locally and synced as soon as the connection comes back, and the eight-second average does not balloon just because the building's wifi took a breath. The guest scans, the kiosk recognises them, the door keeps moving. When the network returns, everything reconciles into one clean record with no double entries and no guests mysteriously missing.
The part guests never see is the reconciliation, and that is the part that matters most. An outage that leaves you with two devices that disagree about who came is an outage that cost you your count. A kiosk that merges its offline work back into a single source of truth means the number you read out to the venue at the end is still the right one.
Plan the kiosk for the worst ten minutes
The temptation when sizing self-service is to plan for the average. Do not. Plan for the worst ten minutes — the surge when a train empties out and everyone arrives at once, on the same overloaded wifi. That is exactly when the network is most likely to buckle and exactly when you most need the kiosks to keep going on their own. If they can hold the line through that window, the rest of the night is easy. Our note on where to place kiosks so the queue keeps moving covers the physical side of surviving that surge.
What to test before the day
You cannot trust a fallback you have never seen fire. Before an event, take a kiosk somewhere with no signal and run a real check-in. Watch what happens. Does it recognise a valid pass. Does it record the check-in. Does it tell you, honestly, when it has reconnected and synced. A kiosk that passes that test on a kitchen table will pass it in front of a queue.
The events that run calmly through a network failure are not the ones with better wifi. They are the ones that assumed the wifi would fail and chose tools that kept working anyway. The drop still happens. The queue just never finds out.
