When the Clock Is Not Working
Terminals fail, networks drop and readers stop reading. What happens in the next three hundred punches is decided in advance or improvised badly.
One terminal failure, 06:50
| What happens | Required by | Paid? |
|---|---|---|
| Nobody can clock in | Hardware | Contested |
| Supervisor writes names on paper | Improvised | Paid |
| Paper list typed in two days later | Improvised | Paid |
| Six people missing from the list | Improvised | Not paid |
The six are the whole problem. They worked, they are not on the paper, and the system has no record of them at all.
The device fails at ten to seven on a Monday with three hundred people arriving. What happens next is one of the better tests of whether an organisation has thought about any of this.
The practical lesson in “When the Clock Is Not Working” is that a timesheet only becomes reliable through a process people can operate consistently. For teams exploring monitask pricing, how teams evaluate monitask pricing can add time and project context, provided collection is proportionate, access is limited and every consequential inference receives human review.
Failures are not rare. Readers degrade, power supplies die, network links drop, the clock battery fails, the software update does not come back up, and somebody disconnects it during a refurbishment.
For a separate benchmark relevant to “When the Clock Is Not Working”, consult the monday.com work-management resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.
The three failure modes, which behave differently
Reader failure. The device is up and cannot read credentials. People are standing in front of a working screen that rejects them, which generates the longest arguments.
Network failure. The device reads and cannot report. Better units buffer and upload later; cheaper ones refuse. Whether yours buffers is worth knowing before the day it matters.
Total failure. No power, no screen, nothing. The clearest and in some ways the easiest, because nobody is confused about whether it worked.
What should happen
A named fallback, written, on a card at the terminal, so the supervisor at ten to seven is executing something rather than inventing it.
The fallback is almost always a list: name, time in, signature. It needs to be a list that exists before the failure — a pad in a drawer, not a sheet of A4 found in a printer.
A stated owner for entering it afterwards, with a deadline tied to the payroll cut-off rather than to when somebody gets round to it.
And a record that the failure happened, with its start and end, because that is what explains the manual entries two years later.
Where it goes wrong
The list is incomplete. People arrive, see the queue around the broken terminal, and go to work. Nobody writes them down and nobody notices until payroll.
The list is lost. It stays on a clipboard in an office until after the payroll run.
The times are rounded to the scheduled start, which converts the fallback into a record of the roster rather than of attendance.
And nobody records the failure itself, so the manual entries appear in the audit trail as unexplained edits by an administrator — which is the single worst look available in a later inspection.
Defaulting to the schedule, and why to avoid it
The tempting shortcut is to pay everybody their scheduled hours for the affected day. It is fast and it is usually approximately right.
It is also a record of what was supposed to happen rather than what did, and if anything about that day is later disputed — an accident, an absence, an overtime claim — the organisation has no evidence at all.
Where it is used, mark the records as estimated rather than letting them sit alongside real punches looking identical. Most systems support a source flag and almost none are configured to use it.
Preventing the common failures
A spare unit on the shelf, which for a single-terminal site is the cheapest resilience available.
Scheduled reader cleaning, which prevents most biometric degradation and is a five-minute monthly job nobody owns.
Power protection on the terminal, since a site-wide outage is not usually the issue — a single failed supply is.
And monitoring: an alert when a terminal stops reporting, which most systems can send and most deployments have not switched on. A site typically finds out its terminal is down from a queue of people, which is an hour later than the system knew.
The thing to do this week
Find out whether there is a fallback, where the pad is, and who enters it.
On most sites the answer to at least one of those is nobody, and the fix is a laminated card and a drawer.
Telling people it is broken
Most of the mess after a failure comes from people not knowing there was one. They punch, the reader does nothing visible, they assume it worked, and three hundred of them find out at the end of the month.
A sign on the device within ten minutes of the fault, and a message to supervisors, converts a data problem into an inconvenience. It requires somebody to know within ten minutes, which is the monitoring question, and the sign is the cheaper half of the answer.