Technical Anshu
Tutorials Blog
🕐 Server Time

Ubuntu Server Wrong Time Breaks Logs Cron Jobs and Certificates

A desktop with a wrong clock shows the wrong time. A server with a wrong clock starts refusing connections, running backups at noon, and writing logs that cannot be trusted in an investigation. Time on a server is not a display preference - it is infrastructure, and this page treats it that way.

✍️ Technical Anshu🐧 Ubuntu⏱️ 7 minute read
🎥 Watch the full video - every Ubuntu time fix shown live, step by step

Four different systems quietly assume your server's clock is true. TLS certificates are only valid between two dates, checked against your clock. Cron and systemd timers fire by your clock. Authentication protocols like Kerberos reject clients whose time differs by more than a few minutes. And logs from several machines only tell a story if their timestamps share one reality. When a server's time is wrong, each of these fails in a different confusing direction - which is why 'the server clock drifted' is diagnosed last and should be checked first.

Terminal - chronyc tracking, the server-grade health readout
$ chronyc tracking Reference ID : A9FE.... (time server) Stratum : 3 Ref time (UTC) : Sun Oct 25 04:44:05 2026 System time : 0.000000842 seconds fast of NTP time
Chrony reports how far the system time sits from NTP time - here, under a microsecond. On a healthy server this offset stays tiny and boring. Example output, shortened.
1

Certificates - the Failure That Looks Like an Attack

  1. Every certificate carries a not-before and not-after date, and your clock decides whether "now" is inside that window
  2. Clock behind reality: fresh certificates look "not yet valid" - sites and APIs refuse with errors that blame the certificate
  3. Clock ahead: perfectly good certificates look expired, including your own server's, so clients cannot connect to you
  4. The same check guards package updates - a badly wrong clock can make repository signatures fail validation, so the server cannot even update its way out
  5. Before renewing or reissuing any certificate in a panic, read the server clock with timedatectl - a one-line check that has saved many needless renewals

"Certificate error" on a server should always trigger a clock check in the first minute.

2

Cron and Timers Run on the Clock You Give Them

  1. A backup scheduled for 2 in the morning runs at 2 according to the server's clock - if that clock is offset, the backup runs in the middle of the working day, or twice around a correction
  2. Log rotation, report mailers, billing jobs and cleanup timers all inherit the same wrong reality
  3. Big backward corrections can make timers skip or repeat, which is why disciplined servers keep the offset near zero continuously instead of fixing it in jumps
  4. Check what your timers believe with systemctl list-timers - the NEXT column is computed from the current clock, wrong or right

A server whose clock wanders does not have reliable schedules; it has approximate ones that fail on the worst days.

3

Logs and Login Systems Keep the Score

  1. Incident work is timeline work: correlating your server's log with the firewall's and the provider's only works if all clocks agree
  2. With drifted clocks, effects appear before causes and honest logs look falsified - an audit and security nightmare
  3. Kerberos, the authentication behind many directory setups, rejects tickets when client and server differ by more than 5 minutes by default - users experience it as "passwords stopped working"
  4. Time-based one-time codes (the 2FA kind) are equally strict: they are literally computed from the clock
  5. Database rows stamped by the server clock inherit the error into your records permanently

This is why experienced admins treat a drifting server clock as a severity-raising fact, not a footnote.

4

The Server Fix - Chrony, Not the Desktop Default

Ubuntu's built-in timesyncd is a fine desktop client, but servers get the proper tool:

  1. Install it: sudo apt install chrony - on Ubuntu this takes over the sync role from systemd-timesyncd
  2. Chrony is built for exactly the server cases: it corrects large offsets after boot or VM restore, tolerates intermittent networks, and disciplines the clock smoothly
  3. Read its health any time with chronyc tracking - the System time line should report an offset of milliseconds or less
  4. See where it is syncing from with chronyc sources
  5. After a known time jump (a restored VM snapshot, for example), force one clean correction with sudo chronyc makestep, then verify

One sync engine, running always, monitored occasionally - that is the whole doctrine.

5

Fleet Discipline - Make Time a Checked Thing

  1. Every server gets working NTP or chrony on day one - before the first service goes live, not after the first incident
  2. Add timedatectl (or chronyc tracking) to your routine health checks; an offset measured in seconds is a warning, in minutes an incident
  3. Virtualised servers deserve double attention - their clocks depend on hosts and snapshots, so verify after every restore or migration
  4. If several servers can sync from one known-good internal source, prefer that: one throat to choke, one clock to verify
  5. Record the offset when you find it, not just the fix - the drift rate tells you whether you have a configuration slip or failing virtual hardware underneath

Teams that check time on a schedule almost never get to debug the four failures above. That is not luck; it is the check working.

🕐 The five-minute rule of thumb: if a server misbehaves in ways that touch certificates, logins or schedules, spend the first minute on timedatectl. It is the cheapest test in this entire series, and on servers it is positive far more often than pride expects.

Watch the Complete Video Guide

The video covers server time end to end - chrony setup, the tracking readout, and the certificate failure that turned out to be a clock all along.

Watch Full Video
❓ Common Questions (FAQ)

Why do certificates fail when the server clock is wrong?

A certificate is only valid between its start and end dates, and your server's clock decides what 'now' means in that check. A clock set before the start makes new certificates look not-yet-valid; a clock set past the end makes good certificates look expired. Both errors point at the certificate, but the fault is the clock.

Is systemd-timesyncd not good enough for a server?

It works, but it is a minimal client: slower to correct big offsets and lighter on monitoring. Chrony is the standard server choice on Ubuntu - it handles VM restores and jumpy networks gracefully and reports its offset precisely with chronyc tracking. For a machine others depend on, that difference matters.

How much clock error is actually dangerous?

Less than people think. Kerberos rejects authentication beyond about 5 minutes of skew by default, and time-based login codes fail within a minute or two. Certificate failures need bigger errors, but log correlation suffers from even seconds of disagreement between machines. A healthy server keeps its offset under a second - aim there.

This guide is based on the Technical Anshu Ubuntu time fix video - stuck on any step, ask in the video comments and you will get an answer.