A server whose clock drifts by just a few minutes keeps working seemingly normally, until that drift silently rejects an otherwise valid TLS certificate, or makes log correlation across several machines inconsistent during an incident. Clock synchronization is one of the most invisible dependencies of an infrastructure, precisely because it almost never breaks loudly.

What TLS validation silently assumes

A TLS certificate carries a start and end validity date, checked against the local clock of the machine examining it, never against an external time source. A server whose clock runs a few minutes ahead of reality can reject an otherwise valid certificate, because its start-of-validity date still looks like it’s in the future from that skewed clock’s perspective.

# A clock running ahead can fail a perfectly
# legitimate TLS validation, with no clear error
# message pointing to the real cause (clock drift, not the cert)
openssl s_client -connect example.com:443 -verify_return_error

What log correlation also assumes

Reconstructing an incident’s timeline from logs across several servers implicitly assumes their clocks are aligned: a gap of a few seconds between two machines can make an event appear to precede its actual cause, distorting exactly the causality order a post-mortem is trying to establish.

chrony: the modern replacement for ntpd

chrony has replaced ntpd as the default implementation on most modern distributions, with a concrete advantage: chrony converges to precise synchronization faster after a reboot or a network outage, and handles the intermittent network connections a physical server can encounter (a workstation going to sleep, a VM migrating between hypervisors) better.

# Sync state in a single command,
# rarely the first diagnostic reflex
chronyc tracking
# Reference ID    : 5EC5D1CB (time.cloudflare.com)
# Stratum         : 3
# System time     : 0.000123456 seconds fast of NTP time

System time shows the actual gap between the local clock and the consulted NTP reference, the metric worth watching continuously rather than assuming synchronization works simply because the service is running.

The trap of a running service that isn’t syncing

An active chronyd service doesn’t guarantee successful synchronization: a firewall blocking the NTP port (123/UDP) toward configured servers leaves the service running without ever actually correcting the clock, a state that often generates no visible alert until someone explicitly checks chronyc tracking.

# Confirms NTP sources are actually reachable,
# not just configured
chronyc sources

Why distributed systems depend on it implicitly

Distributed consensus algorithms (like Raft, already covered for etcd) assume an approximately synchronized notion of time for their timeout and leader-election mechanisms: significant clock drift on a single cluster node can trigger spurious leader elections, a symptom that looks like a network problem when the real cause is a desynchronized clock on just one cluster member.

Takeaway

Clock drift silently breaks TLS validation (a valid certificate rejected by a fast-running clock) and distorts log correlation across several servers, two symptoms that rarely point to the real cause on their own. chronyc tracking reveals in a single command the actual gap between the local clock and the NTP reference, a check worth making explicitly rather than assuming an active chronyd service guarantees successful synchronization. This invisible dependency becomes critical the moment a distributed system (an etcd cluster, for instance) assumes an approximately synchronized notion of time for its own consensus mechanisms.