Is Your Server’s Clock Right?

Keeping accurate time isn’t just nice—it’s essential. Log correlation, TLS certificate validation, Kerberos and OAuth tokens, cron/systemd timers, database replication, and distributed systems all assume your server’s clock is within a few seconds of reality. Here’s a practical, copy‑paste friendly guide to check whether your Linux server’s time is correct and fix it if it isn’t.

TL;DR (Quick Checklist)

1. Confirm the clock & timezone

2. Verify NTP sync is ON and healthy

3. If skewed, do a safe step (schedule off-hours if drift is large)

4. Persist RTC (hardware clock) after fix

5. Allow NTP (UDP/123) and ensure reputable upstream servers are configured.

Step 1 — Check What Time Your Server Thinks It Is

Run these and look for surprises:

You want:

• Local time and UTC to be the expected values for your region.
• System clock synchronized: yes (or equivalent) and an active NTP service.
• A sensible timezone (often UTC on servers).

Confirm the Timezone

If it’s not what you want:

Tip: For most servers, UTC is recommended. If you must run in a local timezone (e.g., appliances with local-only logs, or legal reporting that mandates local time), document it and standardize across hosts.

Step 2 — Verify NTP Synchronization

Accurate servers don’t set time once; they continuously discipline it via NTP.

If you use chrony (common on RHEL, Rocky, Alma, Fedora, Amazon Linux 2023+ and modern Ubuntu):

Healthy signs: small “Last offset” (microseconds to low milliseconds), positive reachability (octal 377 best), and stable frequency.

If you use systemd-timesyncd (lightweight, default on many Debian/Ubuntu minimal installs):

If you use the legacy ntpd (less common on new installs):

Rule of thumb: Prefer chrony for servers. It handles network jitter, virtualization, and suspend/resume scenarios more gracefully than classic ntpd.

Step 3 — Compare Against an External Reference (Optional Sanity Check)

Even when NTP reports healthy, you can sanity‑check offset:

You’re looking for offset within a few milliseconds to tens of milliseconds for well-connected servers. Bigger is okay temporarily during convergence but should settle quickly.

Step 4 — Fix Skew Safely

Assess drift size:

• Small drift (<1s): Let NTP converge naturally.
• Medium (1s–30s): Use a controlled step with chrony.
• Large (>30s or minutes): Schedule a maintenance window—stepping time can confuse apps, cron, and clustered systems.

With chrony (recommended)

Edit /etc/chrony.conf to use reputable sources (pool or vendor/service NTP). Then:

With systemd-timesyncd

With legacy ntpd

Persist to Hardware Clock (RTC)

After you’re happy with the system time, write it to the RTC so reboots start close to correct:

Step 5 — Common Pitfalls & How to Avoid Them

• Firewall blocks UDP/123: Allow outbound NTP to your sources (and inbound if you run an internal NTP server).
• Multiple time daemons fighting: Don’t run chronyd, ntpd, and timesyncd simultaneously. Pick one (prefer chrony) and disable the others.
• Virtualized guests: Avoid host‑guest double discipline. Let either the hypervisor provide time (via paravirtual clock) or the guest use NTP—document your standard. For KVM, ensure kvm-clock/tsc stability and NTP inside the guest.
• Containers: Containers inherit the host clock. Fix the host; don’t try to run NTP inside most containers.
• Bad/ flaky upstreams: Use multiple, diverse NTP sources. Consider your cloud provider’s NTP (e.g., AWS Time Sync, Azure Time) or regional pools.
• RTC localtime vs UTC: Servers should keep RTC in UTC. Check:
  
  timedatectl status | grep RTC sudo timedatectl set-local-rtc 0

  1 2 3

  timedatectl status | grep RTC sudo timedatectl set-local-rtc 0

• Daylight Saving Time surprises: DST doesn’t change UTC, but localtime shifts by ±1h. Prefer UTC on servers to avoid timer/cron confusion.

Distro‑Specific Notes

RHEL / Rocky / Alma / CentOS 7+

• Default: chronyd.
• Key commands:
  
  sudo systemctl status chronyd sudo systemctl enable --now chronyd chronyc tracking; chronyc sources -v

  1 2 3 4

  sudo systemctl status chronyd sudo systemctl enable --now chronyd chronyc tracking; chronyc sources -v

Ubuntu 18.04+ / Debian 10+

• Default varies by image: systemd-timesyncd or chrony.
• Switch to chrony (recommended):
  
  sudo apt-get update && sudo apt-get install -y chrony sudo systemctl enable --now chrony chronyc tracking

  1 2 3 4

  sudo apt-get update && sudo apt-get install -y chrony sudo systemctl enable --now chrony chronyc tracking

Amazon Linux 2 / 2023

• Preferred: chrony using AWS Time Sync (169.254.169.123).
  
  sudo systemctl enable --now chronyd sudo sed -n '1,120p' /etc/chrony.conf | sed -n '1,30p' chronyc sources -v

  1 2 3 4

  sudo systemctl enable --now chronyd sudo sed -n '1,120p' /etc/chrony.conf | sed -n '1,30p' chronyc sources -v

SUSE (SLES/OpenSUSE)

• chrony is available and recommended. Older setups might use ntpd.

Production Hardening & Monitoring

• Pin your upstreams: Use cloud/vendor NTP where available; otherwise use the NTP pool with multiple servers.
• Alerting: Watch for: service down, System clock synchronized: no, large offset, or peer reachability drop.
• Log evidence:
  
  journalctl -u chronyd --since "-1h" journalctl -u systemd-timesyncd --since "-1h"

  1 2 3

  journalctl -u chronyd --since "-1h" journalctl -u systemd-timesyncd --since "-1h"

• Document standard: Timezone (usually UTC), chosen daemon (chrony), upstreams, and how to recover from large drift.

Conclusion

Time drift is silent technical debt—it accumulates until it breaks something at the worst moment. With a few quick checks (date, timedatectl, chronyc) and a standard approach (prefer chrony, keep RTC in UTC, monitor offsets), you can keep your servers within milliseconds of the real world and your operations predictable.