A biometric fleet fails quietly, and the inventory is the last thing to notice. We run 47 registered terminals. Eight of them have never sent a single punch. And 5.54 per cent of the punches we hold came from identifiers that no longer appear in the device list at all.
Those two numbers together are the whole subject of this post. The list of devices and the list of things sending punches are different lists, and every operational surprise lives in the gap between them.
All figures are from our own production data on 31 August 2026, in aggregate. No site or company is identifiable.
Status is a weaker claim than it looks
Our fleet reports 44 devices online and 3 offline. Two of the three offline are explicitly disabled, so as far as the status field is concerned there is exactly one problem in the estate.
By punch traffic, 40 devices have sent something in the last seven days and 3 have been silent for over a month.
Those are not the same picture, and the reason is that status answers a much narrower question than people read into it. It means the device has communicated recently. It does not mean anybody used it, that the right people are enrolled on it, or that its punches matched employees in your system.
Four separate questions, one green dot. In practice, the useful monitor is not "is it online" but "when did a punch last arrive from this specific terminal, and is that normal for this terminal". A door that produces forty punches a day and produced none yesterday is a fault. A door that produces two a month and produced none yesterday is Tuesday.
Eight terminals that have never worked
Eight of 47 registered devices have never produced a punch. Not "not recently". Never.
There is no single cause, and the value of the number is that it is large enough to prove the pattern rather than the incident. A device gets added to the system during setup, in advance of installation. Then it is mounted somewhere, or it is not. It is configured to push to the server, or somebody leaves it pointing at the local PC software it shipped with. Its serial gets typed with a transposition. Nobody checks, because the record exists and the record looks fine.
The register says the estate is 47. The estate that works is 39.
For anyone deploying terminals, the single most valuable step is the least exciting: after installation, punch on it yourself and confirm the punch arrived. Not that the device says connected. That the punch arrived, in the system, with your name on it. Eight devices in our fleet would have been caught in ten minutes each.
The 7,803 punches from devices that no longer exist
The other direction is more interesting, and it is not what we assumed when we first saw it.
Four identifiers with no device record account for 7,803 punches, 5.54 per cent of everything we hold. Two of them are trivial: nine punches carrying the literal source "manual", and two with an empty identifier from early in the dataset.
The other two are real terminals. One produced 4,993 punches between 29 December 2025 and 10 July 2026. The other produced 2,799 between 1 January and 9 July
That is a decommission, a replacement or a site closure, and the important part is what happened to the history: nothing. Seven months of real attendance for real people survived the removal of the hardware record, which is the correct outcome. A punch is a fact about a person, not a property of a device, and deleting a terminal must never delete evidence that somebody was at work.
Worth being precise about what the system does not do, because we assumed wrongly before checking. It does not accept pushes from serials it has never seen. An unregistered serial gets acknowledged and discarded, deliberately: the ADMS protocol has no authentication beyond the serial in the query string, so anyone who guessed one could otherwise post forged attendance records straight into payroll. Devices must be registered by an administrator before their punches count.
So the 7,803 are not strangers being let in. They are former residents whose address was demolished. The practical consequence is the same either way: the current device list cannot account for 5.5 per cent of your history, and any report that joins punches to devices will quietly drop those rows unless somebody thought about it.
The fleet is not evenly loaded
Punch volume is heavily concentrated:
Five doors out of forty-seven carry more than a quarter of the business. Ten carry nearly half.
This changes what good monitoring looks like. Treating terminals as interchangeable and alerting equally on all of them produces a stream of notifications about quiet doors while the important ones get the same weight. An outage on one of the top five is a payroll event. An outage on one of the bottom twenty is a maintenance ticket.
It also changes deployment. The instinct when covering 43 sites is to distribute hardware evenly. The data says capacity should follow the doors people actually use, which means a second terminal at the busiest entrances long before a first one at the quietest.
The model field is 83 per cent noise
A smaller finding, included because it will be true in your estate too.
Of 47 devices, 29 have their model recorded as "ZKTeco", which is the manufacturer rather than a model. Seven say "Not sure which model". Three are blank. Eight carry an actual model name.
Nobody was careless. The field was filled in by whoever installed the terminal, usually from a ladder, from a label that may or may not have been facing them. The lesson is not to nag people into better data entry. It is that a free-text field filled during installation will contain what was knowable at installation, and any process that depends on it, firmware compatibility checks, end-of-life planning, warranty claims, is depending on something that is not there.
If you need the model, read it from the device over the protocol, or accept that you do not have it.
What we would monitor
Last punch per terminal, against that terminal's own baseline. Not a global threshold. The busiest and quietest doors in our fleet differ by four orders of magnitude.
Serials arriving with no device record. These are not errors, they are discoveries: a swapped unit, an unregistered install, a typo being corrected by reality. Ours found four.
Registered devices with no punches, at seven days after install. The cheapest check in this entire post, and the one that would have caught eight.
Concentration, quarterly. Which five doors carry the load. It changes when sites open, close or reorganise, and the monitoring should follow it.
This is how Wurxa attendance monitors a fleet: device health comes from the last time each terminal actually contacted Wurxa, not from a status the terminal reported about itself, so a door that quietly stops sending shows as offline instead of reading healthy. Wurxa connects to the ZKTeco terminals you already own over ADMS push, claimed by serial number, and refuses pushes from serials nobody registered. It is free for up to 5 employees on one site, and every new workspace gets every feature for 14 days with no card. Start your free trial, or read the full dataset.
Put the workflow into practice.
Start with every Wurxa feature for 14 days. No credit card required.
