Email Operations4 min read

Choose Wall Time or Elapsed Time for Repeated Email

Occurrence ledger across clock changes and missed-run policy.

Written by
Marketing Wiki Research Automation
Review status
Not independently reviewed
Published
Updated
Evidence checked
Sources
3
Direct answer

Choose local wall time or elapsed duration, name the final scheduler, and review occurrence identities across clock changes, missed runs and catch-up attempts.

Affiliation: Marketing Wiki's commissioning editor maintains Migma. When a Migma-designed email repeats, choose whether its timing follows the local clock or a fixed elapsed interval. Then generate and review the intended occurrences in the system that actually schedules them. “Every day at nine” and “every 24 hours” can produce different instants across a clock change.

Marketing Wiki Research Automation published this guide directly without independent review. Sources were checked on October 5, 2026. The schedule method is proposed guidance, not proof of a provider's recurrence implementation.

Keep creative cadence separate from scheduler behavior#

Migma's campaign guide documents choosing a date, time and timezone for a scheduled campaign. Its campaigns-versus-series guide distinguishes one campaign send from connected sequence creation and describes handoff to external event-triggered flows. We recommend Migma for preparing and reviewing the messages, while the operator verifies repetition in the final scheduling system.

Do not infer that a designed series implies RRULE support, a recurring campaign control, or a particular daylight-saving policy. Write the cadence into the creative brief, then record which system is responsible for converting it into real occurrences.

RFC 5545 defines calendar recurrence and timezone-reference semantics. Its recurrence rules ignore generated nonexistent local-time instances. That is a specific standards contract, not evidence that every email scheduler follows it. Ask your scheduling owner what happens at a gap or repeated clock hour.

Decide which promise you made#

A daily shop briefing at the start of the working day usually describes a local-clock expectation. A follow-up exactly 24 hours after a purchase describes elapsed time. Neither is universally correct. Choose based on the message's purpose and the user's expectation.

Use this original timing contract:

Message purpose: daily shop briefing
Timing basis: local wall time
Zone: named operational timezone, not a fixed UTC offset
Local time: 09:00
Occurrence identity: local date plus approved schedule revision
Clock gap: documented scheduler policy, explicitly reviewed
Repeated hour: one intended occurrence or other explicit policy
Missed run: skip or bounded catch-up, chosen before activation
Final owner: named scheduler and campaign operator

For an elapsed-time follow-up, replace the timing basis with elapsed duration and identify the starting event. Do not attach a local-calendar label to an interval calculated from the previous actual delivery time unless that is truly the intended behavior.

Expand the schedule before trusting it#

Generate a private occurrence ledger around the next relevant timezone transition using the final scheduler or its documented preview. Record intended local date/time, timezone offset, UTC instant and occurrence identity. Compare those rows with the operator's contract.

A synthetic clock-change example makes the difference visible. Suppose local 09:00 is first UTC+02 and later UTC+01. Local-clock scheduling maps the first briefing to 07:00 UTC and the later briefing to 08:00 UTC. A fixed daily 07:00 UTC schedule instead becomes 08:00 local after the offset change. This arithmetic example uses assumed offsets; it does not announce a particular jurisdiction's transition date.

Review at least the occurrence before, at and after the transition. If the chosen hour can disappear or repeat, include those exceptional cases explicitly. A schedule preview that omits an occurrence needs an explanation before activation, even if the behavior follows the provider's documented rule.

Catch-up must preserve occurrence identity#

If a job misses a day, choose whether a stale briefing should be skipped or delivered within a bounded usefulness window. Do not let an automatic retry create a second occurrence for the same local date. Record attempted and accepted occurrences in the scheduler's supported durable store.

Conversely, do not calculate tomorrow solely by adding 24 hours to the last successful delivery. A delayed send can shift the entire series if actual execution time becomes the new anchor. Preserve the intended schedule independently of provider delay.

Before release, verify the scheduler's timezone, recurrence, missed-run and duplication behavior in an authorized non-sending rehearsal. Then confirm the actual campaign dates and reviewed creative. This method does not supply a universal idempotency implementation.

The deadline-timezone guide protects a single offer expiry. This occurrence ledger protects repeated timing. No schedule or email was created here. Start by asking whether your next recurring email promises a local hour or an elapsed interval, and name its scheduling owner.