AWS Builder Center

Builder Center

Amazon EventBridge Scheduler: 6 Habits That Keep Your Scheduled Jobs Reliable and Cheap

Six small EventBridge Scheduler habits — retry policies, flexible windows, one-time cleanup, least-privilege roles, and explicit timezones — that keep scheduled jobs boring and reliable.

I used to run every scheduled job on a cron daemon sitting on an EC2 instance I also had to patch, monitor, and reboot. The first time that instance died on a Sunday and took three nightly jobs with it, I moved everything to EventBridge Scheduler and never looked back. It is a fully managed scheduler: you define when something should run and what it should invoke, and AWS handles the rest. Six habits keep mine reliable and cheap.
  1. Let Scheduler own the schedule, not a server A schedule that lives on an instance dies with the instance. A Scheduler schedule is just an API object: a cron or rate expression, a target, and a role. No host to patch, no daemon to restart, no 3 a.m. page because cron stopped. If a job still runs from an instance crontab today, that is the first thing I would move.
  1. Give every schedule a retry policy and a dead-letter queue Targets fail. A Lambda throttles, an SQS queue is briefly unavailable, a Step Functions execution gets rejected. Scheduler lets you set a maximum retry count and a maximum event age, and route exhausted invocations to a dead-letter queue. I send every DLQ to an SQS queue with a CloudWatch alarm on its depth, so a failing job pages me instead of vanishing silently.
  1. Use flexible time windows to spread the load Not every job needs to run at exactly 09:00. Scheduler's flexible time windows let a schedule fire any time inside a window you choose, up to 15 minutes. I give all my non-urgent jobs — report generation, cleanup, cache warming — a 15-minute window, so nothing piles up on the hour mark and throttles my own targets.
  1. Delete one-time schedules after they fire One-time schedules are wonderful for delayed work: send a reminder in 48 hours, run a cleanup once, retry a failed step tomorrow. But they pile up fast. I set one-time schedules to delete themselves after completion, and I review the schedule list monthly. A schedule list full of dead one-time jobs is how you stop trusting your own automation.
  1. Scope the IAM role per schedule Scheduler invokes targets with an IAM role you attach to the schedule. That role is the blast radius. I give each job family its own role with exactly the permissions its target needs — invoke one function, send to one queue — and nothing else. A shared admin role on a schedule is a credential leak waiting for a typo.
  1. Treat timezones as a first-class setting Schedules default to UTC unless you say otherwise, and that is where most "it ran at the wrong time" bugs are born. I set the timezone explicitly on every schedule — Asia/Kolkata for my India-facing jobs — and I test anything that crosses a daylight-saving change. A job that fires an hour early in March is not a bug in Scheduler; it is a timezone I forgot to set.
Key takeaways
  • Scheduler replaces cron-on-a-server: no host to babysit, no silent deaths.
  • Retry policy plus a DLQ turns a failed invocation into a visible, fixable event.
  • Flexible windows spread load and stop the top-of-the-hour pile-up.
  • One-time schedules should clean up after themselves.
  • One narrow IAM role per job family keeps a typo from becoming a breach.
  • Set the timezone explicitly, or UTC will decide for you.
Scheduled jobs should be the most boring part of your system. EventBridge Scheduler gets you there — if you give it the same discipline you would give any production code.
# amazon-eventbridge# serverless
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article