Why a server needs accurate time
A clock drift of just a couple of minutes breaks things that rarely get checked manually: TLS certificates, whose validation depends on the exact issue and expiry time; logs that become impossible to correlate across several servers; cron jobs that fire at the wrong time; database replication and distributed systems where event order matters. On a VDS without hypervisor-level synchronization, the clock can drift by seconds per day — enough to build up a noticeable error over a month.
Time synchronization on modern Linux distributions is handled by chrony, a replacement for the classic ntpd and the built-in systemd-timesyncd.
chrony, systemd-timesyncd, and ntpd: the difference
| Tool | Characteristics |
|---|---|
| chrony | converges quickly after a reboot, resilient on unstable networks |
| systemd-timesyncd | a minimal client bundled with systemd, less accurate |
| ntpd | the classic NTP implementation, used less often today |
Ubuntu 20.04+ and Debian 11+ use systemd-timesyncd by default, but on servers where accuracy matters — databases, payment systems, distributed clusters — it's worth installing chrony: it's more accurate and recovers synchronization faster after a virtual machine is paused.
Installing and checking chrony's status
apt install -y chrony
systemctl enable --now chrony
systemctl status chrony
Disable a running systemd-timesyncd so the two clients don't conflict:
systemctl disable --now systemd-timesyncd
On CentOS, Rocky Linux, and AlmaLinux, install the package with dnf install -y chrony; the service has the same name — chronyd.
Configuring time sources
The configuration lives in /etc/chrony/chrony.conf (Debian/Ubuntu) or /etc/chrony.conf (RHEL-based). Sources are set with the pool or server directive:
pool 2.pool.ntp.org iburst
pool time.cloudflare.com iburst
The iburst flag speeds up the initial synchronization right after the service starts. After editing the configuration, the service restarts:
systemctl restart chrony
With a firewall in place, NTP needs outbound UDP port 123 open — with a strict configuration, check this in the rules described in the article on setting up the UFW firewall.
Checking time synchronization
The main chrony diagnostic commands:
chronyc tracking
chronyc sources -v
chronyc sourcestats
chronyc tracking shows the current offset (System time) and synchronization status (Leap status: Normal means everything works fine). chronyc sources -v lists the time sources and marks the one currently in use with an asterisk (*). When the offset stays above a few hundred milliseconds for a long time, check network connectivity to the pool servers.
Common time synchronization problems
- A large offset right after a VDS starts — usually resolves within a minute or two, once chrony completes its first sync with the
iburstflag. - A firewall blocking UDP port 123 — synchronization doesn't happen at all, and
chronyc sourcesshows sources marked as unreachable. - An incorrect timezone — unrelated to NTP but often confused with it: check it with
timedatectland fix it withtimedatectl set-timezone. - chrony and systemd-timesyncd running at the same time — the conflict over the system clock is fixed by disabling one of the services.
For time-sensitive jobs — scheduled backups or reports — make sure chrony is synchronized before a cron scheduler job fires: an offset of a few minutes shifts the backup or report window.
Summary: a server time checklist
- Install chrony:
apt install -y chrony, and disable conflicting services like systemd-timesyncd. - Set NTP sources in
/etc/chrony/chrony.confwith theiburstflag. - Check synchronization with
chronyc trackingandchronyc sources -v. - Open outbound UDP port 123 in the firewall.
- Add a time check to VDS resource monitoring so you catch desynchronization before it breaks backups or certificates.