What Is Clock Skew?

Every computer keeps time with a quartz crystal oscillator. The crystal vibrates at a nominal frequency, and the OS counts those vibrations to advance the clock. The problem is that no two crystals are identical. Temperature, voltage, and manufacturing tolerances make each one run a little fast or a little slow. That rate error is called clock drift, and it is usually quoted as parts per million.

A typical server crystal drifts by 10 to 50 ppm. At 50 ppm a clock gains or loses about 50 microseconds every second, which works out to roughly 4 seconds per day if nothing corrects it. Two machines drifting in opposite directions diverge twice as fast. The gap between what they read at the same moment is the clock skew.

Skew is the standing difference between clocks; drift is the rate at which that difference grows. You correct drift by re-syncing, but the act of measuring time over a network introduces its own uncertainty, so skew never truly hits zero.

Skew breaks any design that orders events across machines by comparing wall-clock timestamps. Last-write-wins conflict resolution is the classic trap: if node B writes a key and node A writes it a few milliseconds later, but B's clock runs 30 ms ahead, A's later write can be discarded because its timestamp looks older. Distributed locks with timeouts, certificate expiry checks, and TTL based caches all misbehave when the clocks involved disagree.

The standard answer is logical clocks, which order events by causality instead of physical time. A Lamport clock is a counter that increments on every event and travels with each message, giving a consistent total order. Vector clocks go further and detect whether two events are concurrent, which is what let Amazon's original Dynamo and Riak flag write conflicts instead of silently losing data.

When you genuinely need physical time for ordering, you bound the uncertainty and design around it. The rule of thumb is simple: if the difference between two timestamps is smaller than your worst-case skew, you cannot trust which one came first, so either fall back to a logical tiebreaker or wait out the uncertainty window.

Login systems set an allowed amount of skew. Kerberos, the login protocol behind Windows domains, rejects a message when the clocks differ by more than its clockskew setting. In MIT Kerberos that limit defaults to 300 seconds, or five minutes. A server whose clock drifts past it starts failing logins with no other fault in sight.

Tokens carry time too. A JWT has an exp claim (expires at) and an nbf claim (not valid before). The JWT standard, RFC 7519, says implementers may allow a small leeway, usually no more than a few minutes, to account for clock skew. Without it, a token issued on one server can look not-yet-valid on another whose clock runs a little behind.

Databases that rely on time often enforce a hard limit. CockroachDB assumes node clocks stay within a maximum offset, 500 milliseconds by default. When a node finds its clock is out of sync with at least half the other nodes by 80 percent of that limit, it shuts itself down. gRPC avoids the problem for deadlines by sending the remaining time, with elapsed time already taken off, so skewed clocks do not shift the deadline. A distributed job scheduler has to handle skew when deciding which jobs are due, and Lamport timestamps give an order that needs no clock at all.

One note on the name: in chip and circuit design, clock skew means something different. There it is the difference in when one clock signal reaches different parts of a circuit. This page is about the distributed-systems meaning, the gap between two computers' clocks.