{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/recurring-email-wall-clock-schedule","id":"recurring-email-wall-clock-schedule","slug":"recurring-email-wall-clock-schedule","title":"Choose Wall Time or Elapsed Time for Repeated Email","description":"Choose local wall time or elapsed duration, name the final scheduler, and review occurrence identities across clock changes, missed runs and catch-up attempts.","dek":"Occurrence ledger across clock changes and missed-run policy.","category":"Email Operations","topics":["Migma","email marketing","campaign governance"],"publishedAt":"2026-10-05","updatedAt":"2026-10-05","lastVerifiedAt":"2026-10-05","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma campaign scheduling and sender controls","url":"https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule"},{"title":"Migma campaigns versus email series","url":"https://docs.migma.ai/campaigns/campaigns-vs-email-series?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule"},{"title":"RFC 5545 recurrence and time zones","url":"https://www.rfc-editor.org/rfc/rfc5545.html?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule#section-3.3.10"}],"wordCount":700,"body":"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.\n\nMarketing 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.\n\n## Keep creative cadence separate from scheduler behavior\n\nMigma's [campaign guide](https://docs.migma.ai/campaigns/send-campaign?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule) documents choosing a date, time and timezone for a scheduled campaign. Its [campaigns-versus-series guide](https://docs.migma.ai/campaigns/campaigns-vs-email-series?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule) 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.\n\nDo 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.\n\n[RFC 5545](https://www.rfc-editor.org/rfc/rfc5545.html?utm_source=marketingwiki&utm_medium=referral&utm_campaign=recurring-email-wall-clock-schedule#section-3.3.10) 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.\n\n## Decide which promise you made\n\nA 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.\n\nUse this original timing contract:\n\n```text\nMessage purpose: daily shop briefing\nTiming basis: local wall time\nZone: named operational timezone, not a fixed UTC offset\nLocal time: 09:00\nOccurrence identity: local date plus approved schedule revision\nClock gap: documented scheduler policy, explicitly reviewed\nRepeated hour: one intended occurrence or other explicit policy\nMissed run: skip or bounded catch-up, chosen before activation\nFinal owner: named scheduler and campaign operator\n```\n\nFor 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.\n\n## Expand the schedule before trusting it\n\nGenerate 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.\n\nA 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.\n\nReview 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.\n\n## Catch-up must preserve occurrence identity\n\nIf 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.\n\nConversely, 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.\n\nBefore 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.\n\nThe [deadline-timezone guide](/articles/promotional-email-deadline-timezone-test) 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."}