GitHub Actions macOS runners: timestamps differ, check your system clock

TL;DR

Add a first step that forces a clock sync against time.windows.com. Use that host specifically; time.apple.com is blocked in the Azure network hosting the runners, so the usual macOS NTP host silently fails there.

Steps

1. Add a first step that forces a clock sync against time.windows.com. Use that host specifically; time.apple.com is blocked in the Azure network hosting the runners, so the usual macOS NTP host silently fails there. This papers over clock drift on the hosted fleet; if the error persists across runs it is worth reporting rather than re-syncing forever.

When to use

You are seeing this: This papers over clock drift on the hosted fleet; if the error persists across runs it is worth reporting rather than re-syncing forever. Use this skill when you run into "GitHub Actions macOS runners: timestamps differ, check your system clock".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: GitHub issue actions/runner#2996 (closed, 15 comments): builds on macos-12 runners fail with timestamps differ by 182 seconds - check your system clock. The reporter got a workaround from support and confirmed it: sync the clock against time.windows.com. The reason the obvious Apple NTP host does not work is that time.apple.com is not reachable from the Azure network where the runners live.

Verified resolution: Add a first step that forces a clock sync against time.windows.com. Use that host specifically; time.apple.com is blocked in the Azure network hosting the runners, so the usual macOS NTP host silently fails there. This papers over clock drift on the hosted fleet; if the error persists across runs it is worth reporting rather than re-syncing forever.

Source URL: https://github.com/actions/runner/issues/2996