CI "Clock skew detected" - Runner Time Drift Breaks Builds/Auth
The runner’s clock disagrees with file timestamps or a remote server. make warns about clock skew when a file’s mtime is in the future; TLS and signed tokens fail when the runner time is too far from real time.
What this error means
A build prints Clock skew detected. Your build may be incomplete, or a TLS/auth step fails with a certificate-not-yet-valid or expired-token error caused by the runner clock being wrong. It clears once the clock is corrected or the runner is replaced.
make: Warning: File 'main.o' has modification time 812 s in the future
make: warning: Clock skew detected. Your build may be incomplete.
# or, from TLS/auth:
x509: certificate has expired or is not yet valid: current time ... is before ...Common causes
The runner clock drifted from real time
A VM whose clock was not synced (NTP not running, a paused/resumed instance, or a freshly booted runner before time sync) can be seconds-to-minutes off, which breaks time-sensitive checks.
Timestamps from a different clock
Files checked out or restored from a cache carry mtimes set by another machine. If those are ahead of the runner clock, make sees "future" files and warns about skew.
How to fix it
Check and correct the clock
Compare the runner time to a reference, and let it sync.
date -u
timedatectl 2>/dev/null | grep -i 'synchronized'
# normalize source mtimes if needed:
find . -newer . -print # spot future-dated filesFix the cause
- Ensure NTP/chrony time sync is enabled on the runner image so the clock is correct at boot.
- For
makeskew from cache restores, normalize timestamps (touchsources) so none are future-dated. - Retry on a freshly synced runner if a transient boot-time drift caused TLS/auth failures.
How to prevent it
- Enable NTP/chrony on runner images so clocks are synced before jobs run.
- Normalize file mtimes after cache restore to avoid future-dated sources.
- Allow a small clock-skew tolerance where signed tokens are validated.