Server Clock Drift on WordPress: Causes, Impact and NTP Fix

An inaccurate server clock is one of the quietest and most disruptive failures a WordPress site can suffer. It does not visibly take the site down, but it silently breaks every system that depends on time: cron, signed APIs, security tokens, replication and logging.

Why this matters

WordPress itself, and almost every serious plugin sitting on top of it, depends on the server clock in several critical places. WP-Cron decides when to run a task based on PHP's time(). If the server clock is ten minutes fast, a backup scheduled for 03:00 actually runs at 02:50; if it is an hour slow, a post scheduled for 09:00 will not go out before 10:00. Beyond that, OAuth and JWT embed a timestamp in the signature and reject requests whose clock differs by more than 300 seconds from the other party - this is the leading cause of "Invalid signature" errors from Stripe, Google APIs and Facebook Graph. New SSL certificates issued via certbot can fail validation under heavy clock skew. Multisite installations with database replication suffer distorted MySQL replication lag. And finally, incident investigation becomes nearly impossible when one log says 14:32 and another says 14:38 for the same event.

How to detect

RankPlus pings its own API, reads the HTTPS Date response header (which relies on accurate UTC) and compares it to time() on the WordPress server. A drift larger than 30 seconds is flagged. You can verify manually over SSH with:

date -u && curl -sI https://www.google.com | grep -i ^date

The two lines should agree to within two seconds. If they diverge, you have drift. Another option: timedatectl status on systemd-based systems will tell you whether NTP is enabled at all and whether the clock is currently synchronised.

How to fix

1. If you have SSH and root, enable built-in NTP synchronisation: sudo timedatectl set-ntp true.
2. On modern systems (Ubuntu 18+, Debian 10+) the service behind the scenes is systemd-timesyncd. Enable it: sudo systemctl enable --now systemd-timesyncd.
3. For more conservative servers use chrony - it is more accurate and behaves better on VMs that suspend and resume: sudo apt install chrony && sudo systemctl enable --now chronyd.
4. Confirm the firewall does not block NTP. The protocol uses UDP port 123 outbound. Some new VPS providers block this by default and you must open it explicitly.
5. If you are on shared hosting without SSH, open a support ticket: "the server clock is not NTP-synchronised - drift is X seconds, please correct".
6. After 2-5 minutes run timedatectl - the System clock synchronized field should read yes.

Common mistakes

• Confusing timezone with clock: WordPress displays times based on the site's timezone (Settings > General). Changing it does not affect the server clock. Fix the server clock in UTC and adjust the user-facing display in WordPress separately.
• Pointing at unreachable internal NTP servers: check /etc/systemd/timesyncd.conf. If it points at a corporate NTP that the box cannot reach, drift accumulates silently.
• Long-suspended VMs: a virtual machine that was paused for hours can resume with a clock minutes off. A one-shot ntpdate is not enough - make sure the daemon runs continuously.
• Docker containers: a container inherits its host's clock. If the host drifts, every container drifts. Fix the host, not each container.

Verifying the fix

Run date -u again and compare to https://time.is or to the Google response header. They should agree. In RankPlus re-run the audit - the status will turn green within the next sampling cycle. Also test a cron event scheduled for a near time - it should fire at exactly the scheduled moment.