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
these were ordinary terminals doing ordinary work. Then, within a day of each
other, both stopped and their device records went away.
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.
Put the workflow into practice.
Start with every Wurxa feature for 14 days. No credit card required.
