Why accurate server time matters (NTP basics)

Why clocks drift in the first place

A server's hardware clock isn't perfectly accurate. It runs slightly fast or slightly slow due to normal variation in its oscillator, and that small error compounds over time. Left alone, a server's clock can drift by seconds or more over the course of days or weeks, more if the hardware clock is particularly imprecise or the server has been running a long time since its last sync. That drift is invisible day to day, until something that depends on accurate time starts failing in ways that look unrelated to the clock at all.

NTP solves this by periodically checking a server's clock against external reference time sources and nudging it back into line, smoothly adjusting rather than jumping the clock abruptly where possible, so that ordinary time-based operations aren't disrupted mid-flight.

What actually breaks when the clock drifts

• TLS/SSL certificate validation. Every certificate carries a validity window with a start and an end date. If a client's clock is far enough off, a genuinely valid certificate can look expired, or not yet valid, and the connection fails even though nothing is actually wrong with the certificate itself. See How SSL/TLS certificates work for how that validity window is checked.
• Time-limited authentication tokens. Some SSH and Kerberos-style authentication schemes, and API request-signing schemes, rely on a token or signature that's only valid for a short window. If a client and server clock disagree by more than that window allows, valid requests get rejected as if they were expired or forged.
• Cron jobs firing at the wrong wall-clock time. A scheduled job is triggered against the system clock, not against some external notion of the correct time. A drifted clock means the job runs early, late, or in the wrong order relative to jobs on other servers.
• Log correlation across servers. During an incident that spans multiple servers, working out the actual order of events depends on timestamps that agree with each other. If each server's clock has drifted independently, stitching together what happened, and in what order, becomes far harder exactly when accuracy matters most.

What makes clock drift particularly frustrating to diagnose is that none of these failures obviously points back to the clock. A certificate error looks like a certificate problem, a rejected API request looks like an authentication bug, and a cron job running at the wrong time looks like a scheduling mistake. Checking the system clock is worth doing early when a failure doesn't otherwise make sense, not as a last resort.

Running an NTP client

The practical fix is straightforward: run an NTP client that keeps the system clock synchronised in the background, rather than relying on whatever the hardware clock happens to read. Modern Linux distributions typically ship with one of two options already available:

• chrony. A full-featured NTP client suited to servers, including ones that are intermittently connected or running in a virtualised environment.
• systemd-timesyncd. A lighter-weight client bundled with systemd, sufficient for straightforward time synchronisation without chrony's fuller feature set.

Either is a reasonable default for a server. What matters is that one of them is actually running and syncing, not which specific client you pick. Check that the sync is active rather than assuming it, a service that's installed but not running provides no protection against drift at all.