allanninal.dev/build

Part 5 of 7 · Warranty registration handler series ~8 min read

How expiry reminders get scheduled

The registration isn’t the end of the relationship; it’s the start of it. A warranty record carries dates that matter months or years away — a service is due, the cover is about to lapse — and something has to notice them at the right moment. This post is about the scheduled sweep that turns those stored dates into well-timed, once-only reminders.

Key takeaways

  • A warranty record carries dates that matter months or years away — a service is due, the cover is about to lapse — and something has to notice them.
  • An EventBridge Scheduler rule runs a sweep on a fixed daily cadence, querying the reminder index for warranties whose next nudge falls due.
  • Two kinds of reminder go out: a maintenance nudge partway through the term, and a pre-expiry heads-up before the cover ends.
  • Each reminder is sent exactly once — the sweep marks it done on the record — and honours the opt-out list, so no one is nagged or double-messaged.
  • The sweep never touches eligibility or claims; it only turns already-stored, already-computed dates into well-timed messages.

The dates that matter later

Registration captures the customer at their most engaged — product in hand, box just opened — and then, if nothing else happens, the relationship goes quiet for years. That silence is a waste. A warranty record quietly holds two moments worth breaking it for: a point partway through the term when a service would keep the product healthy (and the customer happy), and a point near the end when the cover is about to lapse and the customer should know. Neither is triggered by anything the customer does; they’re triggered by a date arriving. A system that only ever reacts to incoming events would sail straight past both, because the thing that needs acting on is the calendar turning over, not a message coming in.

Catching a date needs something that runs on a clock. That’s the reminder sweep: a small scheduled job whose whole purpose is to read the dates every warranty stored back in Part 4 and send the nudge each one has earned, at the right moment and exactly once.

A job on a clock

The sweep is driven by EventBridge Scheduler — a managed cron that invokes a Lambda on a fixed cadence with no always-on compute and effectively no cost. Once a day is plenty; a warranty reminder is not a time-of-day matter, and a day’s granularity across a multi-year term is invisible to the customer. Each run does one simple thing: query the reminder index — the GSI keyed by due date from Part 4 — for every warranty whose next reminder falls on or before today and hasn’t already been sent. Because the dates were computed and indexed at registration, this is a tight query that returns a short list, not a scan across every warranty the business holds.

The two reminders are cut from the same cloth but say different things. The maintenance nudge fires partway through the term — five months into a Cadence e-bike’s life, say, when the first free service is due, or a year into a mattress warranty with a “rotate it and check the support” tip. The pre-expiry heads-up fires a set period before a component’s cover ends: “your Halewood drill’s battery cover ends on 3 October — the tool itself stays covered to 2029.” Both are drawn straight from the stored record, so the dates in the message are the exact ones computed at registration, and both go out through the same messaging path the confirmation used: email by default, SMS where the customer preferred it.

The reminder sweep: a daily job reads the due-date index and sends maintenance and pre-expiry nudges, each once On the left, a box “EventBridge Scheduler” labelled once a day sends an arrow into a box “Sweep Lambda” inside a dotted AWS account container. The sweep Lambda queries the DynamoDB warranties table by its reminder index, a GSI keyed by due date, for records whose next reminder falls on or before today and is not yet sent. The matching records flow to a decision “Which reminder?” that splits into two boxes: “Maintenance nudge”, fired partway through the term, and “Pre-expiry heads-up”, fired before the cover ends. Both feed a box “Check opt-out, then send” that reads a DynamoDB opt-out table and sends the message via SES email or SNS SMS. From there an arrow writes back to the warranties table marking that reminder sent and setting the next due date, so it is never sent twice. A small note beside the table reads opt-out honoured, send once. A bottom note reads: the sweep turns already-stored dates into well-timed messages; it never touches eligibility or claims. EventBridge once a day AWS account Sweep Lambda find what’s due DynamoDB warranties reminder index (GSI) due on or before today query Which reminder? from the record Maintenance nudge partway through Pre-expiry heads-up before it ends Check opt-out, then send SES / SNS mark sent, set next due The sweep turns already-stored dates into well-timed messages — once each — and never touches eligibility or claims.
Fig 5. The reminder sweep. EventBridge Scheduler runs the sweep once a day; it queries the reminder index for warranties due, decides which nudge each earns, checks the opt-out list, sends via SES or SNS, and marks the reminder sent and the next one due — so each fires exactly once.

Once each, and never a nag

The one thing a reminder system must never do is become a pest, so two guardrails sit on every send. The first is exactly-once: when the sweep sends a reminder, it writes back to the record marking that reminder done and setting the next due date — from maintenance to pre-expiry, and after pre-expiry to none. The next day’s run therefore never re-sends the same nudge, even though it re-queries the same index; the “sent” marker is what makes the sweep idempotent, exactly as the escalated flag did in the reference system. If a run half-finishes and repeats, a reminder already marked sent is simply skipped.

The second is opt-out. Every send checks the same suppression list the confirmation respected: a customer who’s asked to stop hearing from the business is never sent a maintenance or expiry reminder, full stop. And the reminders are spaced by design — a service nudge and a single pre-expiry heads-up across a multi-year term is a light touch, not a drip campaign. The system is trying to be useful at two well-chosen moments, not to fill the customer’s inbox. Anything more — a renewal offer, an upsell — is a decision for a person, not something the sweep does on its own.

Why a sweep, and not a timer per warranty

You could imagine scheduling a one-off reminder for each warranty at registration — set a timer for the service date, another for the expiry date, fire each when it comes. It works, but a brand with tens of thousands of live warranties would be juggling hundreds of thousands of individual scheduled entities stretching years into the future, each one a thing to create, amend if the record changes, and clean up. A single daily sweep over a due-date index is far simpler and cheaper: one rule, one function, one query that scales to whatever volume the business has reached, and idempotent by design because the “sent” marker means re-running it never double-messages. The dates live with the data they belong to, on the record, rather than scattered across a scheduler, which also means a correction to a warranty automatically corrects its reminders — there’s no separate timer to remember to update.

And like everything else in the system, the sweep stays firmly in its lane. It reads warranties and their reminder dates, checks the opt-out list, sends a message, and marks the record. It doesn’t decide eligibility, it doesn’t touch claims, and it never messages anyone the confirmation path wouldn’t have. That narrowness is what makes it safe to run unattended, every day, for as long as the warranties it’s watching over remain live.

Design rules that shaped the reminders

  • Act on a date arriving. A reminder is triggered by the calendar, not by the customer, so only a scheduled sweep can see it.
  • A clock, not a trigger. EventBridge Scheduler runs the sweep daily with no always-on compute and effectively no cost.
  • Query the index, don’t scan. The due-date GSI returns just what’s due today, however many warranties are stored in total.
  • Send each reminder once. A “sent” marker on the record makes the sweep idempotent — no nudge ever goes twice.
  • Opt-out is sacred, and the touch is light. Two well-chosen nudges across the term, and none at all to anyone who opted out.
  • One sweep beats many timers. A single daily query is simpler and cheaper than a scheduled entity per warranty, and corrects itself.
All posts