Recurring Emails: Time Zones, Reliable Scheduling and Duplicate Prevention

TL;DR

• A recurring email needs a recurrence rule and an occurrence record; one scheduled timestamp represents only one send.
• Store the intended local time and IANA time zone separately from each calculated UTC execution time.
• Decide what happens during clock changes, missed runs, preference changes and duplicate job delivery.
• Admit each occurrence once, then use a durable sending workflow with clear retry and cancellation states.

A scheduled email and a recurring email are different

A scheduled email says, “send this message at this instant.” A recurring rule says, “produce another message every Monday at 9 a.m. in this time zone.” The latter requires decisions about future dates, recipient eligibility and the content appropriate to each occurrence.

MailBlastr's scheduling documentation describes scheduling an individual email using a future timestamp, with a scheduling window of up to 30 days. That timestamp does not by itself create a weekly series. A recurring workflow must calculate and admit its individual occurrences, then submit the appropriate sends.

Keeping these layers separate also makes cancellation understandable. Canceling one queued email does not necessarily cancel a recurring rule. Turning off the rule does not automatically recall messages that have already been accepted or delivered.

What is a broadcast email?

A broadcast email is a message distributed to a selected audience, such as a product announcement or a newsletter edition. It can contain personalized fields without becoming an individually triggered account message. A recurring broadcast is a series of these audience sends, such as a weekly digest.

A transactional message is associated with a particular application event or account action, such as an order receipt. The implementation can still use a queue or scheduled job. The presence of a timer does not determine whether the message is promotional or transactional.

Define the purpose and category in the product. Apply the preferences and requirements appropriate to that message. Calling a promotion a receipt does not make it one.

Store a rule and a separate occurrence record

A useful recurring-rule record includes the schedule identifier, owner, local time, time zone, recurrence expression, active state and revision. It should also capture what content or reporting period the series represents.

Each occurrence then records its own identifier, rule revision, intended date, resolved execution time and state. A unique database constraint on the appropriate rule-and-occurrence identity helps prevent two workers from admitting the same occurrence. If a broadcast contains many recipients, use a corresponding occurrence-and-recipient identity for recipient sends.

For a fictional Monday digest, the occurrence key might mean “the digest for the week beginning on this local date.” It should not change merely because a worker retries five minutes later. Keep the provider's message identifier as a separate field because it represents a later sending operation.

Preserve the user's time-zone intention

Use an IANA zone such as America/New_York or Asia/Kolkata for a local-time schedule. A fixed offset captures an instant's relationship to UTC, but it does not express future changes in a location's clock rules.

For a digest intended at 9 a.m. local time, calculate each occurrence from the calendar rule in the selected zone. Do not repeatedly add 24 hours to the previous UTC timestamp and assume that preserves the same local hour through every clock change.

Google Cloud Scheduler's time-zone guidance describes daylight-saving anomalies in wall-clock schedules and recommends UTC for workloads needing a fixed cadence. The choice depends on the promise: “every 24 hours” and “at 9 a.m. here every day” are different requirements.

Show the next few calculated runs in the interface using the selected zone. Keep a clear label when the viewer's current zone differs from the publishing zone. A user traveling abroad should not silently change a team's established schedule merely by opening its settings.

Define daylight-saving and missed-run behavior

Some local times do not exist during a clock change, while another time may occur twice. Choose a policy before the scheduler encounters it. For example, a noncritical digest might move a nonexistent occurrence to the next valid local time and use only the first instance of a repeated time. That is a product decision, not a universal rule.

Also define the catch-up window. After a three-day outage, sending three old daily digests immediately is often less useful than sending the latest relevant edition. An invoice reminder may need a different rule. Record skipped occurrences and their reason so support can distinguish a deliberate skip from a lost job.

Use a time-zone-aware date library and test its actual ambiguity options. Keep time-zone data updated with the application runtime. A prose policy is insufficient if the selected library defaults to different behavior.

Generate content for the right reporting window

Give every digest an explicit start and end for the data it summarizes. Resolve those boundaries in the relevant reporting zone, then query using the resulting instants. A delayed worker should still know which period the occurrence represents.

Decide whether the content is a snapshot approved earlier or a fresh summary prepared at dispatch. Both can be valid, but mixing them creates confusing results. For example, an edition's subject should not say “last week” while its body includes events through the moment a retry happened.

Keep a content revision or hash with the admitted occurrence. It helps explain what was sent without retaining unnecessary personal data in application logs. Avoid rebuilding a different message under the same idempotency key after an ambiguous provider response.

Recheck eligibility and make cancellation precise

Before dispatch, recheck the rule's active state, recipient preferences and any changing business condition. A previously eligible recipient may have unsubscribed or closed an account since the occurrence was first planned.

Separate states such as planned, admitted, submitted, canceled and skipped. A cancellation should say what it actually stopped. Once the provider has accepted the message, the application may no longer be able to prevent delivery; use the provider's documented cancellation window where available.

When editing a rule, increment its revision and decide how pending occurrences are replaced. Keep old records for explanation rather than modifying their meaning. If an operator moves a single edition, make that override visible without unintentionally shifting every future edition.

Retry the operation, not the entire series

A durable outbox lets a worker retry a send after the occurrence has been admitted. Pair it with the provider's documented idempotency mechanism and your own durable occurrence identity. MailBlastr's idempotency guide explains the API behavior; provider retention windows do not replace a permanent business record of completed occurrences.

Back off on retryable failures, stop on permanent errors and make exhausted attempts visible. Avoid a second scheduler independently submitting the same series without sharing the admission constraint. Two healthy workers can still create duplicate mail if they disagree about which system owns the occurrence.

Test a calendar, not just one timestamp

Check the next several occurrences for a normal week, both daylight-saving transitions where applicable, a month boundary and a rule edit. Include a stopped rule, a changed recipient preference, an expired reminder, a duplicate job and a timeout after possible provider acceptance.

Verify the number of admitted occurrences and provider submissions, not only the displayed date. Use authorized test recipients and keep test messages clearly separate from customer editions. The workflow is ready when its behavior matches the written policy in both ordinary and exceptional cases.

Frequently asked questions

Can one scheduled API request send an email every week?

A single scheduled timestamp represents one email. A recurring workflow needs a scheduler to calculate and admit future occurrences, unless the product explicitly provides a recurring feature with the required semantics.

Should I use UTC for every recurring email?

UTC is useful for a fixed cadence. A schedule promised in a user's local time should preserve that local-time intention using a named time zone and an explicit clock-change policy.

Does canceling an edition stop the whole series?

Only if the product explicitly implements that behavior. Provide separate actions for one occurrence and the recurring rule, with clear handling of already-submitted messages.

Is a weekly digest always marketing email?

Its purpose, content and recipient relationship matter. Frequency alone does not decide the category. Apply the appropriate preferences and requirements rather than classifying solely by schedule.