The Time Lords Are Retiring the Leap Second — Your Servers Are Still Drifting: How to Catch Clock Skew Before It Breaks Kerberos, Logs, and Alerts

Somewhere in the standards world, the time lords are preparing the most significant change to civil timekeeping in half a century: retiring the leap second. With Earth's rotation speeding up and a never-before-seen negative leap second now a genuine risk, the plan on the table would let UTC drift away from solar time — potentially by as much as an hour — and kick the reckoning to the year 3000. The leap second, added 27 times since 1972, would be history by 2035.

Fantastic news for metrologists. Roughly zero help for you.

Because while the standards bodies argue about planetary time, your infrastructure is quietly drifting every single day. The Hyper-V host that paused a VM last night and resumed it 47 seconds behind your PDC emulator. The firewall rule change in March that silently cut off outbound UDP 123 to your external NTP source. The member server someone pointed at pool.ntp.org instead of the domain hierarchy in 2019 that has been freewheeling ever since.

And here's the part that stings: the first place this shows up is almost never your monitoring dashboard. It's a Kerberos error on a user's screen. An expired certificate warning on a backup job. A patch reboot that landed in the middle of a client's business hours. Your uptime checker says everything is green — because a server can be six minutes slow and still answer a ping.

What a Few Seconds of Drift Actually Costs

Clock drift never announces itself. It degrades six things at once:

1. Authentication dies first. Active Directory's Kerberos rejects tickets when client and server clocks differ by more than five minutes (the default MaxClockSkew). That's where the classic Monday-morning ticket comes from: The trust relationship between this workstation and the primary domain failed. Users can't log in, and the helpdesk starts chasing group policy ghosts when the real answer is dc01's clock is 6 minutes slow.

2. TLS validation breaks next. Agents and backup software validating certificates against a badly skewed clock start failing handshakes — certificate not yet valid or expired — which cascades into failed update pulls and backup jobs that look exactly like credential problems.

3. Log correlation becomes fiction. Your app server logs a database failure at 02:14:33. Your DB server says it was healthy until 02:12:10. With 90 seconds of skew between them, neither timeline is trustworthy, and an incident that should take 15 minutes to triage takes 90. (Forensics bonus: if your logs from a GPS-disciplined source are exactly 18 seconds off from everything else, that's the leap-second offset GPS time carries — GPS has never included leap seconds.)

4. Your SLA data quietly lies. Monitoring tool in UTC, servers in local time, Task Scheduler in local time — suddenly alerts appear to fire in the future, deduplication fails, and nobody trusts the response-time report you're presenting to the client or the board.

5. Maintenance windows misfire. A file server running 40 minutes slow fires its 2 a.m. backup at 2:40 a.m., eats into the patch window, and the reboot that was supposed to finish by 4 a.m. collides with early users. On an MSP-managed client, that's exactly the kind of thing that gets escalated to the account manager.

6. Distributed systems lose their footing. Replication lag calculations, event ordering, transaction timestamps — all of it assumes clocks roughly agree. When they don't, you get phantom conflicts and impossible event sequences.

None of these look like a time problem from the outside. They look like authentication failures, storage failures, and network failures — which is precisely why they eat hours.

Why Your Current Stack Never Catches It

Run the honest audit. If your time-sync coverage depends on the tools most IT teams run today, here is what you actually have:

• Standalone uptime checkers confirm the port is open. A server can be six minutes slow and report 100% uptime.
• Classic monitoring has NTP checks — as a community plugin, configured host by host, feeding a separate alert stream nobody tuned after the original deployment.
• Your RMM is superb at patch status and AV health. Time-sync health is rarely a first-class metric, and its alerts carry no ticket context.
• The helpdesk receives the symptom — can't log in — with zero telemetry attached. The tech remotes in, opens Event Viewer, finds Kerberos errors, and eventually thinks to check the clock. Twenty minutes of detective work that a single metric would have skipped.

Five tools, five timestamps in three formats, zero shared timeline. That's not a skills problem. That's an architecture problem — siloed agents, bolt-on integrations, and no shared incident view — and it's why a 47-second drift turns into a three-hour, fifteen-ticket incident.

How AlertMonitor Puts Time Back on Your Side

AlertMonitor was built on a simple premise: one agent, one pane of glass, one alert stream. Applied to clock drift, that changes the entire lifecycle of the problem:

• Time-sync health is a first-class monitored metric. Offset from the authoritative source, sync status, and last successful sync are monitored across servers, Windows workstations, and network devices. Set thresholds that actually matter: warn at 5 seconds, go critical at 240 seconds — before Kerberos slams the door at 300.
• One incident timeline, normalized to UTC. The Kerberos failure, the scheduled-task canary that didn't fire, and the NTP-offset alert land in the same incident with a timeline that adds up. No cross-referencing five tabs to figure out what happened in what order.
• The alert becomes a ticket, automatically. AlertMonitor's integrated helpdesk creates the ticket with diagnostics attached: current offset, configured source, last sync time, relevant event log entries. Your tech starts at the root cause, not at have you tried restarting?
• Remediate from the console that found it. The RMM side lets you push the resync script remotely, and the automated follow-up check verifies the offset is back under one second before anyone closes anything.
• Patching respects real time. Maintenance windows are enforced consistently across clients, with canary checks confirming scheduled tasks actually fired in-window — across every client in your NOC.
• Topology shows the broken path. If member servers lost reachability to your DC over UDP 123, the network map makes that obvious in seconds.

The old way: user tickets at 8:40 → remote session → Event Viewer archaeology → someone remembers to run w32tm → fix → 60+ minutes, fifteen tickets, one very annoyed sales floor.

The AlertMonitor way: offset crosses 240 seconds at 6:12 a.m. → critical alert to on-call with diagnostics → auto-ticket → remote resync → verified back under 1 second → closed before the first coffee. Ten minutes, zero user-facing tickets.

Practical Steps: Audit and Fix Your Fleet Today

Before you change anything, find out how bad it is. This PowerShell snippet measures the offset between a known-good machine (your PDC emulator or a synced admin workstation) and every server in your fleet:

# Audit NTP offset across your Windows fleet.
# Run from a machine you KNOW is in sync (e.g., your PDC emulator).
$servers = Get-Content C:\temp\servers.txt

foreach ($server in $servers) {
    # w32tm stripchart measures offset between this machine and the target
    $raw = w32tm /stripchart /computer:$server /samples:1 /dataonly 2>$null

    if ($raw -match ',\s*(?<off>[+-]?[0-9.]+)s') {
        $offset = [double]$Matches.off
        $state  = if ([math]::Abs($offset) -ge 300) { 'CRITICAL - Kerberos at risk' }
                  elseif ([math]::Abs($offset) -ge 5)   { 'WARNING' }
                  else { 'OK' }
        '{0,-25} {1,12:N4}s  {2}' -f $server, $offset, $state
    }
    else {
        '{0,-25} {1,12}  {2}' -f $server, 'no reply', 'CHECK W32TIME / UDP 123'
    }
}

Any server over 300 seconds of offset is a live Kerberos incident waiting for Monday morning. Fix it like this:

# Repair a domain-joined Windows server that stopped syncing from the domain hierarchy
w32tm /config /syncfromflags:domhier /update
Restart-Service w32time -Force
w32tm /resync /force
w32tm /query /status

On the Linux side of the house, chrony tells you everything in three commands:

# Is this server actually in sync?
timedatectl status
chronyc tracking        # check the System time offset line
chronyc sources -v      # which NTP peers, and their reach

# Force an immediate step if the offset is large
sudo chronyc makestep

Finally, add a canary that catches time problems indirectly but reliably: scheduled tasks that stop firing on time. If a task's last run time drifts outside its window, clock skew or scheduler failure is usually the reason:

# Canary: did the nightly maintenance task run inside its window?
$task   = Get-ScheduledTaskInfo -TaskName 'Nightly-Maintenance' -TaskPath '\Custom\'
$cutoff = (Get-Date).AddHours(-26)

if ($task.LastRunTime -lt $cutoff -or $task.LastTaskResult -ne 0) {
    Write-Warning ('Nightly-Maintenance last ran {0} (exit code {1}). Possible clock skew or scheduler failure.' -f $task.LastRunTime, $task.LastTaskResult)
}
else {
    Write-Host ('Nightly-Maintenance OK - last ran {0}' -f $task.LastRunTime)
}

Then wire these into real monitoring: a time-sync check with a 5-second warning threshold and a 240-second critical threshold on every server and workstation, feeding the same alert stream as your disk, service, and patch checks. That's a five-minute configuration in AlertMonitor — and it's the difference between a 6 a.m. page to on-call and fifteen locked-out users at 8:40.

The Bottom Line

The time lords have until 2035 to decide how UTC evolves, and their solution is to let the discrepancies pile up slowly enough that nobody alive needs to care. Your infrastructure doesn't have that luxury. It drifts by the second, every day, and the failure modes land on authentication, backups, patching, and your SLA reports simultaneously.

You can't stop the drift. You can make sure something is watching for it — in the same place that watches everything else.

Related Resources

AlertMonitor Infrastructure & Server Monitoring

AlertMonitor Platform Overview

Book a Demo

Infrastructure & Server Monitoring Resources