AWS EventBridge Cron Generator

AWS EventBridge cron uses a 6-field expression wrapped in cron(...) — cron(0 9 ? * MON-FRI *) runs every weekday at 9 AM UTC. The fields are minute, hour, day-of-month, month, day-of-week, year, with a mandatory ? for one of dom or dow. Use the form above to build an expression with a live UTC run preview, and copy-paste IaC snippets for CloudFormation, Terraform and the AWS CLI.

Why does AWS EventBridge cron need 6 fields?

cron(minute hour day-of-month month day-of-week year)
       0      9        ?        *     MON-FRI    *
      0–59  0–23   1–31 / ?    1–12  1–7 / ?    *

Five gotchas, in priority order:

1. Six fields, not five. Standard Unix cron is * * * * *. AWS is * * * * ? * — the trailing * for year is mandatory, even though it’s almost always *.
2. ? is required. Day-of-month and day-of-week can’t both be * (or both restricted) — exactly one of them must be ?. The ? means “I’m not specifying this field”.
3. Day-of-week is 1–7, not 0–6. AWS numbers Sunday as 1 through Saturday as 7, where standard Unix cron numbers Sunday as 0 through Saturday as 6. Use the named form (SUN, MON, …, SAT) to sidestep the off-by-one entirely.
4. All times are UTC. Original EventBridge Rules have no timezone option. Use EventBridge Scheduler (the newer service) if you need a timezone — same cron syntax, but you set ScheduleExpressionTimezone separately.
5. No @daily, @hourly shortcuts. Those are Vixie cron extensions. AWS only accepts the explicit 6-field form.

Common AWS cron expressions

How do I run on the first Sunday or last Friday of the month?

AWS EventBridge accepts two day-of-week operators that standard Unix cron doesn’t — # for nth occurrence, and L for last. They’re the only way to express schedules like “first Sunday of the month” or “last business day” without external orchestration.

• # — the nth occurrence. SUN#1 is the first Sunday of the month, MON#3 is the third Monday, FRI#5 is the fifth Friday (skipped in months with only four). The numeric form works too — 1#1 equals SUN#1, 2#1 equals MON#1. Valid only in the day-of-week field; n must be between 1 and 5.
• L — the last. In day-of-week, FRIL (or 6L) is the last Friday of the month. In day-of-month, plain L is the last day of the month, and L-3 is three days before the last day.

Two practical gotchas:

1. L standalone in day-of-week is Saturday, not “any last weekday”. AWS treats Saturday as the last day of the week (because day-of-week starts at Sunday=1). To target a specific last weekday of the month, prefix it: 5L or FRIL for last Friday.
2. You still need ? in the field you’re not constraining. cron(0 9 ? * SUN#1 *) keeps ? for day-of-month — without it AWS rejects the expression because dom and dow can’t both be specified.

Both operators behave identically in EventBridge Rules and EventBridge Scheduler — the timezone capability is the only difference between the two services, not the cron syntax.

How do I convert my local time to UTC for AWS cron?

If your team is in IST (UTC+5:30) and you want a job to run at 9 AM IST:

9:00 IST = 03:30 UTC  →  cron(30 3 * * ? *)

If you’re in PST (UTC-8) and want 9 AM PST:

9:00 PST = 17:00 UTC  →  cron(0 17 * * ? *)

Daylight saving complicates things — UTC has none, so a “9 AM PST” job will silently run an hour earlier in the eyes of users on PDT. If that matters, use EventBridge Scheduler with a timezone instead of converting to UTC.

How do I use the expression in CloudFormation, Terraform or the CLI?

AWS CLI — put-rule with a schedule expression:

aws events put-rule \
  --name daily-cleanup \
  --schedule-expression "cron(0 2 * * ? *)" \
  --state ENABLED

CloudFormation — EventBridge Rules:

DailyCleanupRule:
  Type: AWS::Events::Rule
  Properties:
    Name: daily-cleanup
    ScheduleExpression: 'cron(0 2 * * ? *)'
    State: ENABLED
    Targets:
      - Id: cleanup-lambda
        Arn: !GetAtt CleanupFunction.Arn

CloudFormation — EventBridge Scheduler (with timezone):

DailyCleanupSchedule:
  Type: AWS::Scheduler::Schedule
  Properties:
    Name: daily-cleanup
    ScheduleExpression: 'cron(0 9 * * ? *)'
    ScheduleExpressionTimezone: 'America/Los_Angeles'
    FlexibleTimeWindow:
      Mode: 'OFF'
    Target:
      Arn: !GetAtt CleanupFunction.Arn
      RoleArn: !GetAtt SchedulerRole.Arn

Terraform — EventBridge Rule:

resource "aws_cloudwatch_event_rule" "daily_cleanup" {
  name                = "daily-cleanup"
  schedule_expression = "cron(0 2 * * ? *)"
}

Terraform — EventBridge Scheduler:

resource "aws_scheduler_schedule" "daily_cleanup" {
  name                          = "daily-cleanup"
  schedule_expression           = "cron(0 9 * * ? *)"
  schedule_expression_timezone  = "America/Los_Angeles"
  flexible_time_window {
    mode = "OFF"
  }
  target {
    arn      = aws_lambda_function.cleanup.arn
    role_arn = aws_iam_role.scheduler.arn
  }
}

Triggering a Lambda from EventBridge cron — the permission gotcha

EventBridge can target a Lambda directly, but the call only goes through if Lambda also grants invocation permission to the EventBridge service principal. Miss this and the schedule fires successfully while Lambda silently rejects every invocation with AccessDeniedException in CloudWatch.

Rules invoke Lambda via a resource-based permission. Add this alongside the AWS::Events::Rule (or aws_cloudwatch_event_rule):

RuleInvokeLambdaPermission:
  Type: AWS::Lambda::Permission
  Properties:
    Action: lambda:InvokeFunction
    FunctionName: !Ref CleanupFunction
    Principal: events.amazonaws.com
    SourceArn: !GetAtt DailyCleanupRule.Arn

resource "aws_lambda_permission" "allow_events" {
  statement_id  = "AllowExecutionFromEventBridge"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.cleanup.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.daily_cleanup.arn
}

Scheduler is different — it invokes through an IAM role. The Scheduler examples above already include RoleArn/role_arn; that role needs an inline or attached policy granting lambda:InvokeFunction on the target Lambda’s ARN. No AWS::Lambda::Permission resource is required for Scheduler-invoked targets.

EventBridge Scheduler vs EventBridge Rules

For new schedule-driven projects, use EventBridge Scheduler. Launched in late 2022, it’s AWS’s purpose-built cron service and has several capabilities Rules don’t.

Per-schedule timezones

EventBridge Rules evaluate every cron expression in UTC. Scheduler accepts a ScheduleExpressionTimezone (any IANA zone — America/New_York, Asia/Tokyo) per schedule, so cron(0 9 * * ? *) with timezone America/Los_Angeles fires at 9 AM Pacific year-round, daylight saving included. The cron string itself is unchanged.

One-time schedules with at(...)

Scheduler accepts a third expression type Rules don’t — at(2026-12-25T09:00:00) runs the target exactly once at that wall-clock time. Pair with a timezone for any zone. Use it for delayed work (invoice generation 30 days after signup, account-deletion grace periods, scheduled feature flags) without spinning up Step Functions.

Flexible time windows

The FlexibleTimeWindow property lets Scheduler fire any time within a window after the nominal cron time, smoothing thundering-herd patterns at scale. Mode: OFF keeps strict cron semantics; Mode: FLEXIBLE with MaximumWindowInMinutes: 15 lets the invocation drift up to 15 minutes for load-spreading.

Retries and dead-letter queues

Scheduler retries failed invocations (configurable retry count and maximum event age) and routes undeliverable events to an SQS DLQ. Rules don’t natively retry cron-triggered Lambda invocations beyond Lambda’s own async retry semantics.

Scale

A single account can hold up to a million Scheduler schedules per region. Rules have a default quota of 300 rules per event bus (raisable to a few thousand) and per-target invocation TPS capped lower than Scheduler.

When should I migrate from Rules to Scheduler?

Migrate if you need any of: timezones, one-time schedules, retry/DLQ, or more than ~300 schedules per account. The cron syntax is identical between the two services — the migration is mostly a resource-type swap (AWS::Events::Rule → AWS::Scheduler::Schedule), not a schedule re-write. Stay on Rules if your existing IaC works and you’re under those limits — there’s no deprecation pressure on Rules for cron use cases.

When should I use a cron vs a rate expression?

EventBridge accepts two schedule expression types:

• rate(N units) — fires every N minutes / hours / days starting from when the rule was created. Use for “every 30 minutes” jobs where the actual minute doesn’t matter.
• cron(...) — fires on a specific clock pattern. Use for “every weekday at 9 AM UTC”, “the 1st and 15th of every month”, anything with calendar semantics.

If your only requirement is “run every N minutes”, rate(N minutes) is shorter and harder to get wrong. Use cron(...) when the wall-clock time matters.

Related

• Generic cron expression builder — for Unix / Linux / GitHub Actions schedules.
• Kubernetes CronJob schedules — 5-field syntax + ConcurrencyPolicy gotchas.