A reminder is a business event before it is a push message.

A reminder can be technically delivered and still be wrong: it arrives overnight, refers to a completed task or repeats after a retry. The notification system needs to understand the business event before handing text to a delivery provider.

A concrete product reference

UltraFit360’s notification guide describes scheduled processors, user timezones, preferences, a queue, delivery logs and throttle records. The backend source contains queue processing and cooldown operations. These are useful boundaries to reuse. They do not establish a universal delivery rate or an engagement improvement.

Split eligibility from attempts

For a SaaS renewal reminder, the event might be an account approaching a renewal date. Eligibility depends on the renewal still being relevant, the recipient’s preferences and the intended local-time window. Delivery attempts belong to that event. A provider timeout should create another attempt under the policy, not another renewal event.

Use local time without losing an absolute clock

Store a user or workspace timezone as a named zone and represent execution timestamps unambiguously. Decide whether a reminder follows the account timezone or the recipient timezone. Test daylight-saving changes and a timezone edited after a reminder is queued. Avoid inferring a permanent timezone from a single numeric offset.

Bound repetition across channels

A cooldown for one message subtype does not automatically prevent several other message types arriving together. Define a broader cap where appropriate and coordinate email, push and in-app delivery. Keep transactional requirements separate from optional engagement reminders so one policy does not silently override another.

Design for stale work

Before delivery, decide whether the underlying task or subscription must be checked again. A reminder that was useful at queue time may be obsolete later. Keep cancellation and superseded states visible so a queue can explain why an event did not produce a message.

Verify the failure cases

• Two processors attempt the same event concurrently.
• The provider accepts a request but the response is lost.
• The recipient changes preferences while work is queued.
• A token expires or the device changes.
• The task completes just before dispatch.

For a B2B product, the useful measures include duplicate sends, stale reminders and the ability to investigate a complaint. Increasing send volume alone is not proof that the system works better.

Reference: Expo delivery and receipts