Time Synchronisation: What Breaks When Clocks Drift
Clock synchronisation is infrastructure nobody thinks about until something breaks in a way that makes no sense. It is cheap to get right and awkward to diagnose when it is wrong.
What breaks when clocks drift
Four things, and they fail in ways that do not point at the clock.
Log correlation becomes impossible. Investigating an incident means putting events from several systems in order. If their clocks disagree, the sequence is wrong — and you can reach a confident conclusion about cause and effect that is simply backwards.
Authentication fails. Many authentication protocols reject requests where the timestamp is outside a tolerance, because that is how replay attacks are prevented. A machine whose clock has drifted stops being able to authenticate, and the error message rarely mentions time.
Certificates behave oddly. Validity is checked against the local clock, so a machine with a wrong date may reject valid certificates or accept expired ones.
Scheduled work runs at the wrong time, or twice, or not at all. Backups and maintenance windows overlap with production in ways nobody planned.
The pattern worth recognising: time problems present as authentication problems, certificate problems and inexplicable log sequences. If a machine has started failing to authenticate for no clear reason, check its clock early.
How synchronisation should be structured
A simple hierarchy, and the mistake is usually not having one.
A small number of internal sources synchronise to an external reference. Two or three, not one — a single source is a single point of failure for the entire estate's timekeeping.
Everything else synchronises to those internal sources rather than reaching out independently.
Two reasons that structure matters. It means your estate agrees with itself even if the external reference is briefly unreachable, which is what log correlation actually needs. And it means devices that cannot reach the internet still keep good time.
Where accuracy requirements are strict — some regulated environments specify traceable time — a dedicated appliance with its own reference is the answer, and it is a specification worth confirming rather than assuming.
The devices people forget
Servers usually get configured. These frequently do not.
Management controllers. They have their own clocks, separate from the operating system, and they timestamp the hardware event logs you rely on during an incident. A controller with a wrong clock makes its own log useless — our management guide covers configuring them.
Network switches and firewalls, whose logs matter most in exactly the investigations where sequence is critical.
Storage arrays and appliances.
Cameras, door controllers and access systems, where the timestamp on a recording may need to stand up to scrutiny — our chain of custody guide covers why that matters.
Point-of-sale terminals and label printers, where the timestamp appears on receipts and labels. A date-coded label with the wrong date is a real problem in food and pharmaceutical contexts — our cold chain guide covers the consequences.
The rule worth applying: anything that writes a timestamp anyone will later rely on needs correct time. That is a longer list than most estates have configured.
Practical points
Four.
Battery-backed clocks fail. Most equipment keeps time while powered off using a small battery, and those batteries die. A machine that loses its clock every time it is powered down has a dead battery — a trivial part, and an easy thing to misdiagnose as something complicated.
Time zones and stored time are different questions. Storing timestamps in a single reference zone and displaying local time avoids the ambiguity that daylight saving transitions create — where an hour repeats, and log entries appear out of order.
Isolated networks still need time. A network with no internet access needs an internal source, and this is regularly overlooked when a segment is deliberately isolated — our isolated networks guide covers what such segments still require.
Monitor drift. A device that has stopped synchronising does not announce it; it just slowly diverges. Include clock offset in what you watch — our monitoring guide covers routing that somewhere a person reads.
Getting it right on new equipment
Two habits worth building into deployment.
Configure time during commissioning, alongside network settings and management access, rather than as a follow-up. Our acceptance testing guide covers what belongs in that checklist.
Set the management controller separately from the operating system, since they are configured independently and the controller is frequently missed.
And when investigating any incident, check the clocks of the systems involved before trusting the sequence of events. It takes a minute and it occasionally saves you from a completely wrong conclusion.
Common questions
Why did authentication suddenly start failing?
Check the clock. Many authentication protocols reject requests whose timestamp falls outside a tolerance, because that is how replay attacks are prevented — and the error message rarely mentions time.
How should synchronisation be structured?
Two or three internal sources synchronised to an external reference, with everything else synchronising to those. That way your estate agrees with itself even when the external reference is briefly unreachable — which is what log correlation actually needs.
Which devices get forgotten?
Management controllers, which have their own clocks separate from the operating system and timestamp the hardware logs you rely on during an incident. Also switches, firewalls, storage arrays, cameras, access systems, POS terminals and label printers.
My machine loses the time whenever it is powered off. Why?
A dead clock battery. Most equipment keeps time while powered off using a small battery, and those die — a trivial part, and an easy thing to misdiagnose as something more complicated.
Do isolated networks need time synchronisation?
Yes, from an internal source. This is regularly overlooked precisely because the segment is deliberately isolated, and the result is a network whose logs cannot be correlated with anything.
If you are commissioning equipment, configure time alongside network settings rather than as a follow-up, and set the management controller separately.
