The Time delay element behaves differently depending on which delay option you picked, and every option is evaluated in the device's own timezone. Emails arriving 'too early' almost always mean the step is not using the option you assumed.
- Fixed duration — the user waits the configured period (maximum 30 days) from the moment they reach the step.
- Specific time — the user proceeds at that clock time in their own timezone. If the time has already passed when they reach the step, they wait until that same time the next day — they are not released immediately.
- Date (a specific calendar date and time) — if that date and time have already passed in the user's timezone, the user proceeds immediately to the next element. This is the option that causes emails to go out straight away.
- Day of week — if the day and time have passed, the user waits until the same day and time next week.
- Based on user/event data (a date from a Tag, event attribute or webhook response) — if the resulting date is already in the past, the user exits the journey, unless you enable Split to branches if the date's in the past or date is empty and handle them on the In the past branch.
What to check when emails were sent earlier than expected
- Open the Time delay step and confirm which delay option it uses — Date (and a past date) releases users at once.
- If you meant a recurring daily send time, use Specific time.
- Remember that devices with an unknown timezone use the journey's fallback timezone, which can shift the evaluation.
- Once a device passes the delay, the following Email element sends to the address linked to that device's User ID, so several devices of the same user can trigger sends at different local times.
Comments
0 comments
Please sign in to leave a comment.