How can clock drift or timing issues affect automation?

You set up a delay-send automation: "Send this email 24 hours after purchase." But your payment processor's server clock is 3 minutes ahead of your ESP's server clock. Small difference, right? Except that the automation fires at the wrong time. Or doesn't fire at all. Or sends twice.

Clock drift happens when different systems have slightly out-of-sync clocks. Your server, your ESP, your payment processor, your data warehouse. They're all measuring time, but not exactly the same time. When automation spans multiple systems, those small differences add up.

The practical problems are real. A delay-send you calculated to fire in 24 hours might fire in 23 hours 57 minutes because the timestamp checking was off. Triggers that should fire at a specific moment might miss the window entirely if system A thinks it's 3pm and system B thinks it's 2:57pm. If two systems check the same condition at "the same time," they might disagree on whether to proceed because they're reading the clock differently.

Sometimes automation sends twice because the retry logic re-triggered, or a contact qualification check happened twice and got counted twice. These race conditions happen quietly. The recipient gets two order confirmations. Your metrics look inflated. You don't always notice until someone complains.

Mitigation is mostly boring infrastructure work. Sync your systems to a central time source like UTC using Network Time Protocol. Log timestamps from a single source rather than letting each system measure time independently. Add buffer zones around time-sensitive triggers. If you're delaying 24 hours, make it 24 hours plus 5 minutes. The extra cushion prevents the timing window closing too early.

Deduplication logic also helps catch problems you don't prevent upstream. Build in idempotency checks so the same event triggering twice doesn't send two emails.

Next step: check your current delay-send automations. Note which systems hand off time data to each other. If you're bouncing timestamps between your payment processor, a data warehouse, and your ESP, that's a clock-drift risk zone. Run a quick sync check (most platforms have time zone and UTC settings). Then add a 5-minute buffer to any mission-critical delay sends.