When It Is the Network, Not the Reader

A substantial share of what sites experience as reader failures are not reader failures. The device is working, the templates are intact, and it cannot reach the thing it needs to reach.

The failure described in “When It Is the Network, Not the Reader” is easier to investigate when the clock event is joined to a clear operational record instead of treated as proof of misconduct. A team reviewing Monitask resources for attendance point system for attendance point system should test retries, missed punches, corrections and employee review while preserving a non-biometric fallback that does not depend on finding a supervisor.

What happens next is a configuration choice with three common settings, and the difference between them is the difference between an inconvenience and a morning of lost records. Very few sites know which one they are running.

For an independent benchmark relevant to “When It Is the Network, Not the Reader”, consult the EEOC retaliation guidance. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.

The three behaviours

Fail closed: the terminal refuses everybody until the connection returns. Clean from a control standpoint and operationally severe, because three hundred people arrive and nothing works.

Fail open: the terminal accepts without matching, recording that it did so. Keeps the queue moving and records presence, at the cost of identity assurance for the duration.

Offline with cached templates: the terminal holds a local copy, matches locally, buffers the reads, and uploads them when the link returns. This is the right answer and it requires the device to have the storage and the licence for it, which on cheaper units it may not.

Finding out which one you have

Ask, and then test. Testing means unplugging the network cable at the terminal during a quiet hour and presenting a credential.

Most sites discover one of two things. Either the behaviour is not what the documentation says, or nobody can produce documentation at all. The test takes ten minutes and it answers a question that will otherwise be answered during an outage by three hundred people standing in a doorway.

What happens to the buffered reads

The reads taken offline have to arrive somewhere, and the join is where the problems are. Do they come in with their original timestamps or with the time of upload. Do they arrive as normal entries or flagged as something else. Does the payroll run that happens before the reconnection pick them up at all.

A terminal that buffers correctly and uploads with the upload time has produced a record that is worse than useless: it looks authoritative and it is wrong by however long the outage lasted. This is worth testing deliberately, because it only shows up on days nobody is watching.

Clock drift during the outage

Terminals keep their own time and drift, and they usually correct against a network time source. During an outage there is no correction, and a device that drifts a few seconds a day will be noticeably out after a week disconnected.

The reads buffered during that period carry the drifted time. On reconnection some systems correct them and some do not, and which yours does is a question with a specific answer that nobody has looked up. For a short outage it does not matter; for the week a site was off the network after a cable strike, it does.

The outage nobody notices

The most damaging case is not the obvious one. It is the terminal that lost its connection on a Friday, buffered quietly, filled its local store on Tuesday and started discarding reads, and was noticed on Thursday when somebody queried a payslip.

Monitoring for this is trivial and almost never configured: an alert when a terminal has not reported in for an hour. Without it, the site's first indication is a gap in the data, found weeks later, with no way to reconstruct who was present.

The three lines to hold with the documentation

Three lines, held with the system documentation. Which behaviour each terminal is configured for. How many reads it can buffer and for how long. And who is alerted when it stops reporting.

Then one line for the people at the terminal: what they should do when the screen says it cannot connect. On most sites the honest current answer is "find a supervisor", which is the same answer as for every other problem and is why the override log is the size it is.

Telling people which failure they are looking at

From the doorway, a dead reader, a dead network and a refused finger look identical: the thing does not work. The response to each is different and the person standing there has no way to tell them apart.

Most terminals display something distinguishable if anybody has looked — a connection symbol, an error code, a different tone. Putting the three states on the card at the terminal, with what to do for each, converts a general sense that the clock is broken into three specific situations with three specific answers.