Timezone bugs: why your production automation crashes at 3 AM on a Sunday
Over the last two years we have fixed more automations broken by timezone mistakes than by real API outages. Why these bugs hide so well, where they strike most often, and the three rules that prevent them.
Timezone bugs are the hardest production failures to spot
If you have built any automation that runs on a schedule, sends scheduled messages, or filters records by date, you have a timezone bug somewhere. The only question is whether you have found it yet.
Last Sunday at 03:14 a client's Slack alert went off. An invoicing workflow had sent 47 dunning notices it should not have. Recipients in Frankfurt, Vienna, New York. The cause: a routine daylight saving switch the night before.
We know that call. It comes on weekends. Nobody understands at first why a workflow that has been running cleanly for eight months suddenly collapses. The reason almost always reduces to three letters: UTC.
Over the last two years we have repaired more automations broken by timezone mistakes than by real API outages. They are harder to spot, harder to reproduce, and they almost always cost more to fix than the original automation took to build.
The problem is not time. It is data.
Every platform handles dates differently. Make stores workflow schedules in the workspace owner's timezone. n8n defaults to UTC but lets you override per workflow. Zapier uses the account timezone, but incoming webhook payloads carry their own. HubSpot returns date fields in UTC and renders them in whichever timezone the viewer is logged in from. Salesforce stores UTC and exports differently depending on org settings.
None of this is hidden. All of it is documented. But nobody reads the documentation before the first bug shows up, and by then the workflow has been live for months.
The bug is not that the platforms disagree about time. The bug is that the workflow assumes they agree.
The three places these bugs hide
We see the same three patterns over and over.
Day boundaries. A workflow runs at 23:55 every night to "process today's tickets". The server is in UTC. The team is in Berlin. In summer that is a two-hour offset. By the time the workflow fires in UTC it is already past midnight in UTC, so the filter "tickets from today" misses everything created between 22:00 and 23:55 Berlin time. Six hours of data, vanished without an error.
Daylight saving transitions. Twice a year, Europe shifts by an hour. Some platforms handle this automatically in their cron schedules. Some do not. A workflow that is supposed to fire "every weekday at 9 AM" might fire at 8 AM after the switch, or skip a day, depending on how the scheduler interprets the offset.
International recipients. You send a reminder email saying "your appointment is tomorrow at 2 PM". The recipient is in Tokyo. By the time they open it, "tomorrow" is already today, and your "2 PM" is somewhere between 9 PM their time and 4 AM the next day. We have seen real customers locked out of services because the automation defined "today" as server time, not as customer time.
Three rules we enforce before any workflow goes live
Before a workflow goes into production, we make sure three things are true.
Rule 1: Store everything in UTC. Database, CRM field, or spreadsheet, the canonical timestamp is UTC. Convert to local time only at display, or when the recipient receives the message. This one rule eliminates most of the problems we see.
Rule 2: Never schedule a cron job without an explicit timezone. "9 AM" is ambiguous. "9 AM Europe/Berlin" is not. Make, n8n, and Zapier all support timezone-aware scheduling, and they all have different defaults. If you did not pick one explicitly, you are trusting the default, and the default will change something twice a year.
Rule 3: Define day boundaries as ranges, not magic. When filtering "events from tomorrow", do not write `created_at = today() + 1`. Write `created_at >= [start of tomorrow in UTC] AND created_at < [end of tomorrow in UTC]`. The math is annoying. The result is correct.
A 15 minute audit you can run today
Pick your five most important automations. For each one, answer three questions.
What timezone does the trigger run in? Do not guess. Check the logs, not the UI. Make shows the workspace timezone in the top right. n8n displays it in the workflow settings. Zapier shows it in the account profile. Write it down.
What format are the date fields going in and out? Pull two records from the source system and compare them to what arrives downstream. If they look slightly different, you have a quiet timezone bug waiting to surface.
What happens at the next daylight saving switch? In the EU, the next one is October 25, 2026. Put it in your calendar. The morning after, verify every scheduled workflow ran on time. We do this every year. Every year we find at least one job that needs a manual nudge.
Why standard QA misses this
Because timezone bugs hide inside time itself. A workflow with a daylight saving issue is broken on exactly two days a year. A workflow with a day-boundary issue breaks only on records near midnight, usually less than one percent of traffic. A workflow with an international recipient bug only fails when a specific user from a specific timezone hits a specific edge.
Standard QA catches none of this. Stage environments use server time. Manual tests get run during business hours. Nobody schedules a test run for 02:00 on the last Sunday of October.
If your automations touch dates, schedules, or users in more than one timezone, you have these bugs. Whether you find them before the next 3 AM Slack message is up to you.
If you are not sure which of your active workflows have these gaps, our free Automations Check is worth a look. We will walk through your list together and prioritize which ones to lock down first.