Why it matters
A scheduled action needs a durable record of what should run, when it should run and what happens if it runs late or twice. A cron expression alone does not carry that product state.
A scheduled task is a promise that something will happen later. Your product needs to know whether it ran, whether it failed and whether a customer changed their mind in the meantime.
Decisions to make
- Choose between global recurring jobs and customer-specific schedules.
- Define timezone and daylight saving behavior.
- Set retry, cancellation and late-run policies for each job type.
- Choose between one-off jobs, recurring schedules and durable workflows.
- Define the timezone and daylight-saving behavior shown to the user.
Build checklist
- Persist job identity and intended execution time.
- Make handlers idempotent and observable.
- Test duplicate delivery, cancellation, clock changes and missed runs.
- Persist the next run and execution outcome.
- Test duplicate execution, delayed execution and cancellation near the due time.
Common mistakes
- Relying on an in-process timer for durable customer work.
- Assuming a cron expression represents a customer’s local time forever.
- Using an in-process timer for work that must survive deployments.
Tools & references
4 starting points to compare or study. Check fit, maintenance, terms and current capabilities before choosing one.
