At 2:47am UTC, the first error appears in the logs. By 2:51 UTC, the cascade has started. The on-call engineer is paged at what their phone displays as 10:47pm — they are in San Francisco, where it is still Wednesday evening. Their counterpart in Berlin, who joins the call ninety seconds later, is working from what their clock shows as Thursday morning at 3:47am.
The incident is real and unfolding. The logs are in UTC. The engineers are in different timezones. The status page needs to be updated with a human-readable incident timeline. The postmortem will need to be written for a global audience. Every timestamp in every log line needs to be mentally converted by every person reading it, in real time, under pressure.
This is log file limbo — the cognitive tax of operating infrastructure that logs in UTC while humans work in local time.
UTC is the correct choice for logging. It is unambiguous, it does not shift with DST, and it allows events from systems in different regions to be sequenced accurately on a single timeline. There is no serious argument for logging in local time.
The problem is the translation layer. Converting "2026-03-08 02:47:33 UTC" to "Sunday 10:47pm San Francisco / Monday 03:47am Berlin" is not hard, but it is a task that requires attention, and attention during a severity-one incident is a scarce resource. Every second spent on timezone arithmetic is a second not spent on diagnosis.
The practical responses are: use tooling that displays timestamps in the reader's local timezone automatically; include both UTC and local time in incident communications; and when writing postmortems, anchor the timeline in UTC with local equivalents noted in parentheses for the primary regions involved.
The mental tax is real. Quantifying it is hard. But any engineer who has worked an overnight incident involving teams in three timezones has felt it.