Fix VPS Clock Drift With NTP Time Sync (Chrony Guide)

If your VPS is throwing SSL handshake failures that make no sense, cron jobs firing at the wrong time, or WHM suddenly refusing to log you in with a vague licensing error, don't rule out the obvious: check the server's clock. A drifted system clock is one of those problems that looks like five different problems at once, and most admins never think to check date until they've already spent an hour chasing certificates and firewall rules.

Symptom: A Grab-Bag of Unrelated-Looking Errors

Clock drift rarely announces itself directly. Instead you get a pile of side effects that seem unconnected:

• Browsers or curl reject a perfectly valid SSL certificate with SSL: CERTIFICATE_VERIFY_FAILED or "certificate is not yet valid."
• Certbot/Let's Encrypt renewals fail with signature or clock-related errors even though the domain and DNS are fine.
• Cron jobs run late, early, or seemingly skip a run entirely.
• WHM or cPanel throws login or licensing errors, since cPanel's license check is time-sensitive.
• Log timestamps don't line up with what actually happened, which makes debugging anything else harder.
• API calls to services that check request timestamps (AWS S3, some payment gateways) get rejected outright.

None of these scream "check the clock" on their own. That's exactly why it's worth ruling out early instead of last.

Cause: The System Clock Drifted and Nothing Is Correcting It

Every server has a hardware clock that drifts a little over time due to temperature, hardware quality, and just plain imprecision. On a physical machine this is usually small. On a VPS it can be worse, because the hypervisor's virtual clock can drift more noticeably under load, especially after a host migration, a snapshot restore, or the VM being paused and resumed.

Normally a background service (chronyd, ntpd, or systemd-timesyncd) talks to NTP servers every so often and nudges the clock back into line. If that service isn't installed, isn't running, or is blocked from reaching NTP servers on the network, the drift just accumulates until something breaks loudly enough that you notice.

Check how far off you actually are before doing anything else:

date -u
# compare against a trusted source, e.g. https://time.is or
timedatectl status

On AlmaLinux/Rocky/CentOS, timedatectl status will show whether NTP is even enabled:

               Local time: Fri 2026-07-24 14:02:11 UTC
           Universal time: Fri 2026-07-24 14:02:11 UTC
                 RTC time: Fri 2026-07-24 13:41:57
                Time zone: UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive

System clock synchronized: no and NTP service: inactive is your confirmation. If the clock is off by more than a few seconds and nothing is syncing it, that's your root cause.

Fix: Install and Enable Chrony (or systemd-timesyncd)

Chrony is the modern default on both AlmaLinux/Rocky and current Ubuntu/Debian releases, and it's faster to sync a large drift than the older ntpd. Here's how to get it running properly on each.

AlmaLinux, Rocky Linux, CentOS Stream

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc tracking
chronyc sources -v

chronyc tracking should show a small "System time" offset (fractions of a second) once it's synced. If it's still hours off right after install, give it a minute or two, then re-check — chrony steps large offsets gradually by default unless you force it.

To force an immediate step-correction instead of waiting for chrony to slew slowly toward the right time:

sudo chronyc makestep

Ubuntu / Debian

Ubuntu ships with systemd-timesyncd by default, which is fine for most VPS use cases:

sudo timedatectl set-ntp true
timedatectl status

If you want chrony instead (useful if you run time-sensitive services and want tighter sync, or your provider's default NTP pool is flaky):

sudo apt update
sudo apt install -y chrony
sudo systemctl disable --now systemd-timesyncd
sudo systemctl enable --now chrony
chronyc tracking

Set the Correct Timezone Too

Clock sync fixes the absolute time, but a wrong timezone will still make your logs and cron schedule confusing. Set it explicitly rather than guessing:

sudo timedatectl set-timezone UTC
# or, for example:
sudo timedatectl set-timezone Asia/Kolkata

We generally recommend running servers on UTC and converting in your application or monitoring layer — it avoids daylight-saving surprises in cron schedules and log correlation across servers in different regions.

If NTP Traffic Is Blocked

Chrony and timesyncd use UDP port 123 to reach NTP servers. If your VPS sits behind a restrictive firewall (CSF, UFW, or an upstream network ACL) and outbound UDP/123 is blocked, sync will silently fail. Confirm with:

sudo ufw status | grep 123
# or for CSF
grep -i "123" /etc/csf/csf.conf

Allow it outbound if it's missing, and if your hosting provider gives you an internal NTP endpoint, point chrony at that instead of a public pool for lower latency:

# /etc/chrony.conf
server ntp.your-provider-internal.net iburst

Restart chronyd after editing the config: sudo systemctl restart chronyd.

Prevention: Make Sure It Stays Fixed

A one-time sync doesn't help if the service falls over again next month. A few things worth setting up once and forgetting:

If you use monitoring (Netdata, Zabbix, or even a basic cron-driven check that emails you if chronyc tracking reports an offset over a threshold), add clock drift as a checked metric. It's cheap to monitor and expensive to debug blind.

One more habit worth adopting: after restoring a VPS snapshot or moving it to a new host, always run chronyc makestep or restart the NTP service. The clock can freeze during the pause and come back stale, and a fresh sync clears that up in seconds.

Frequently Asked Questions

How much clock drift actually causes problems?

SSL/TLS validation and most APIs start rejecting requests once the gap exceeds roughly 60-90 seconds, though the exact threshold depends on the client and certificate. Cron misfires and WHM licensing issues can show up with even smaller drift. If chronyc tracking shows more than a couple of seconds of offset and isn't correcting itself, it's worth fixing regardless of whether you've seen symptoms yet.

Why did my clock suddenly drift after I restored a snapshot?

Snapshots freeze the VM's internal clock at the moment it's paused. When you restore it later, the guest OS often resumes thinking almost no time has passed, even though hours or days went by on the host. Chrony or timesyncd will correct it automatically within a few minutes once network access is up, but a manual chronyc makestep speeds that up if you need things working immediately.

Should I use chrony or systemd-timesyncd on Ubuntu?

For a typical web/app server, systemd-timesyncd is fine — it's lighter and syncs well enough for HTTPS, cron, and logging. Switch to chrony if you're running something more time-sensitive (distributed databases, financial or logging systems that need tight synchronization), since chrony handles larger corrections faster and gives you more visibility via chronyc tracking and chronyc sources.

Can a wrong clock actually break cPanel or WHM login?

Yes. cPanel's licensing daemon checks the system time against cPanel's license servers, and a large enough mismatch can cause license validation to fail, which in turn blocks WHM access with a licensing-related error. It's one of the more confusing ways clock drift shows up, because the error message points nowhere near "check your NTP service."

Do I need to restart services after fixing the clock?

Anything that cached a timestamp before the fix — active SSL sessions, some database connections, long-running cron processes — may still behave oddly until it restarts naturally or you restart it. After a large step-correction, it's worth restarting web server, database, and mail services (systemctl restart httpd nginx mysqld exim, whichever apply) just to be safe, especially if the drift was large.