Time Synchronization (NTP/chrony)
Clock drift silently breaks TLS certificate validation, cron scheduling, log correlation across machines, and time-based auth tokens - chrony (or the lighter systemd-timesyncd) keeps a machine's clock synced to a reliable external source automatically.
An unsynced clock fails quietly - nothing crashes immediately, things
just start behaving wrong in ways that don't obviously point at the
clock: a curl request to an HTTPS endpoint failing certificate
validation because the cert's validity window doesn't overlap with the
machine's (wrong) idea of the current time, log timestamps across a
fleet of machines that don't actually line up when correlating an
incident, a scheduled cron job
firing at the wrong wall-clock moment, or a time-based one-time password
(TOTP) rejected because the server's clock has drifted too far from the
client's.
Checking current status
timedatectl
Local time: Sat 2026-08-29 14:32:01 UTC
Universal time: Sat 2026-08-29 14:32:01 UTC
RTC time: Sat 2026-08-29 14:32:01
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
System clock synchronized: yes is the line that actually matters -
confirms the system is both configured to sync and has succeeded
recently, not just that a time sync service happens to be installed.
chrony: the modern standard
sudo apt install chrony # Debian/Ubuntu
sudo dnf install chrony # Fedora/RHEL, often preinstalled
chronyc tracking
Reference ID : C0A80101 (ntp.example.com)
Stratum : 3
System time : 0.000012529 seconds fast of NTP time
Last offset : +0.000015831 seconds
System time shows the current measured offset from the reference
source - a well-synced machine stays within milliseconds, not seconds.
chronyc sources -v
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com 3 6 377 23 +120us[+180us] +/- 8ms
^* marks the currently-selected best source; Stratum counts hops
from an authoritative reference clock (stratum 1) - lower is generally
more directly authoritative, though chrony's source selection already
accounts for this automatically.
systemd-timesyncd: the lighter built-in alternative
Many distributions ship systemd-timesyncd enabled by default -
simpler than chrony, sufficient for typical desktop and general server
use, but less precise and without chrony's ability to also serve time
to other machines on a network:
systemctl status systemd-timesyncd
sudo timedatectl set-ntp true # enable/disable syncing
If both chrony and systemd-timesyncd are installed, only run one at a
time - they'll otherwise fight over the same job. Installing chrony
typically disables systemd-timesyncd automatically on most distros;
worth confirming with systemctl status systemd-timesyncd if sync
status ever looks inconsistent.
Time zone vs. time sync: two separate settings
Syncing keeps the underlying clock (always UTC internally) accurate; the time zone only affects how that UTC value is displayed locally - mixing these up is a common source of confusion:
timedatectl list-timezones | grep America
sudo timedatectl set-timezone America/New_York
Servers are conventionally kept on UTC regardless of physical location - avoids daylight-saving-time ambiguity in logs and scheduled jobs entirely, since UTC never shifts.
Firewall requirement
NTP uses UDP port 123 outbound to reach time servers - rarely an issue since outbound traffic is commonly allowed by default, but worth knowing if a restrictive egress firewall (see Firewalls: iptables and nftables) is blocking sync silently:
sudo ufw allow out 123/udp