EventBridge Scheduler: Define the Business-Time Contract Before the Cron

Choose local-time cron, elapsed-duration rate or one-time schedules. Record DST, delivery windows, business cutoffs and completion evidence separately.

Primary sources checked 2026-10-17

Choose a local-time cron expression when the job belongs to a civil calendar, a rate expression when it belongs to a repeating duration, and a one-time schedule when one dated occurrence has been approved. Before enabling any of them, record what the business expects when the local time disappears, repeats, arrives late or produces an uncertain result. A schedule expression cannot supply those decisions.

This guide helps an application engineer and business owner define that contract for one EventBridge Scheduler schedule in one account and Region. The output is a reusable decision record: a recurrence and evidence manifest that separates intended occurrences, target delivery and accepted work. The worked scenario is a daily internal reporting job whose recipient, data scope and completion rule are already agreed. All dates, job records and incident paths below are illustrative. No AWS schedule, target, permission, message or log was created, invoked or inspected.

The scope excludes holiday-calendar administration, database-job migration, human staffing coverage, subminute timing, cross-Region failover and a target-specific retry implementation. The Classic EventBridge and Lambda failure guide explicitly excludes Scheduler. Its settings must not be copied into this different service. For a downstream Lambda/SQS worker, use the separate serverless failure-boundary guide after identifying the actual integration.

1. Translate the business request into a recurrence choice

Ask the owner to finish the sentence “one accepted result is due for...” before selecting a syntax. A local business date, an elapsed interval and a customer-selected appointment describe different identities. If a team says “daily” while the operator means every 24 hours and the recipient means 08:30 in Los Angeles, both can configure a valid expression and still deliver the wrong service.

The CreateSchedule API supports cron and rate expressions for recurrence, and at(...) for one-time scheduling. It also separates the expression from its evaluation timezone. The following choices are proposed for the stated requirements, not universal defaults.

Prepare the local weekday brief at 08:30 Los Angeles time

Candidate expression and interpretation: cron(30 8 ? * MON-FRI *) with America/Los_Angeles

Condition that changes the choice: A public-holiday exclusion needs a separately owned business calendar

Poll a permitted source every 24 elapsed hours

Candidate expression and interpretation: rate(1 day) with an explicit first-occurrence anchor

Condition that changes the choice: If the local clock label must stay constant, use local-time cron

Run one approved review on 17 November 2026 at 08:30 Kolkata time

Candidate expression and interpretation: at(2026-11-17T08:30:00) with Asia/Kolkata

Condition that changes the choice: If the selected local time is ambiguous or nonexistent, resolve it before creating the occurrence

Write the exception policy beside the expression. MON-FRI is a weekday filter; it does not encode local public holidays, an office closure or the customer's own accounting calendar. Adding an application calendar gate can be suitable if the application retains an explicit skipped-by-policy record and the calendar owner can correct it. Silently dropping the job leaves the operator unable to distinguish an approved closure from a missing occurrence.

A business process that starts its next run only after the previous run finishes needs an additional decision. A recurring expression describes opportunities to invoke the target. It does not, by itself, establish a completion-relative interval or prevent overlapping work. Decide whether unfinished work blocks, replaces or coexists with the next occurrence, and name the component that enforces that rule.

2. Pin the calendar assumptions and inspect the DST edges

AWS documents IANA timezone support, skipping a cron occurrence at a nonexistent spring time, and invoking only once when the local time repeats in autumn. It describes a rate-based day as 24 hours. It also documents minute-level invocation precision, so the expression does not promise execution on an exact second. These are Scheduler schedule-type rules, not evidence that a particular job completed.

For the fixtures below, the calendar reference is IANA tzdb 2026e. Its North America rules give Los Angeles a standard offset of UTC minus eight hours and the US seasonal rule. Its Asia data gives Kolkata UTC plus five hours thirty minutes for these dates. Under those pinned rules, the Los Angeles spring transition is 8 March 2026 and the autumn transition is 1 November 2026.

These tables are reasoned expectations using those calendar inputs and AWS's general recurrence rules. They are not captured service output. The local reproduction environment must record its parser version, timezone-data release or digest, and interpretation settings. AWS's deployed timezone-data release has not been established here. A local library agreeing with this table does not prove that an AWS configuration uses identical rules.

S1, spring control

Specified local occurrence: Daily 02:30 Los Angeles, 7 March 2026

Expected calendar interpretation: Valid time, corresponding to 10:30 UTC

Decision for the owner: Retain the ordinary occurrence and its completion requirement

S2, spring gap

Specified local occurrence: Daily 02:30 Los Angeles, 8 March 2026

Expected calendar interpretation: That clock label does not exist; Scheduler's documented cron policy skips it

Decision for the owner: Accept an explicit calendar skip or commission a different occurrence policy

S3, following day

Specified local occurrence: Daily 02:30 Los Angeles, 9 March 2026

Expected calendar interpretation: Valid time, corresponding to 09:30 UTC

Decision for the owner: Resume the normal recurrence without inventing a make-up run

F1, autumn repeat

Specified local occurrence: Daily 01:30 Los Angeles, 1 November 2026

Expected calendar interpretation: The local label maps to 08:30 UTC and 09:30 UTC; the documented cron policy invokes once

Decision for the owner: Do not create two business jobs from the repeated label; exact service-selected UTC candidate remains unverified here

N1, non-DST control

Specified local occurrence: Daily 08:30 Kolkata, 8 March and 1 November 2026

Expected calendar interpretation: Each occurrence corresponds to 03:00 UTC under the pinned rules

Decision for the owner: Keep the Kolkata business date even though another region changes clocks

For F1, preserve both possible UTC candidates in the expected manifest until the applicable service behavior is resolved. The general AWS rule supports one invocation, but this guide does not claim which candidate an observed schedule selected. If the business deadline depends on the first or second occurrence specifically, hold that requirement for a controlled test or use explicit, resolved UTC occurrences. Do not let a local parser's default ambiguity choice become an undocumented AWS guarantee.

An elapsed-duration comparison exposes the choice. Stipulate a first rate occurrence at 8 March 2026, 09:30 UTC, which is 01:30 before the Los Angeles spring shift. Adding 24 hours gives 9 March, 09:30 UTC, which is 02:30 local. A local 01:30 cron occurrence on 9 March instead corresponds to 08:30 UTC. Neither interpretation is intrinsically wrong. The owner must decide whether the interval or the civil-clock label expresses the job.

Pinning a reference release makes the review reproducible, not permanently correct. IANA explains that offsets and seasonal rules change with political decisions. Recheck future occurrences after relevant rule changes, runtime updates or timezone edits. Retain the old expectations so a changed UTC mapping has an explanation rather than appearing to be unexplained scheduler drift.

3. Set a delivery window and a separate business cutoff

Suppose the illustrative weekday brief is scheduled for 08:30 local and the business owner accepts publication before 09:00. The output must contain the agreed source cut and a recipient-accessible result reference. The 09:00 boundary is an exclusive deadline in this example: publication at or after 09:00 is late. Another workload can choose an inclusive boundary, but it must record it explicitly.

A flexible window allows intentional dispatch dispersion. AWS's flexible-window guide describes a configured window after the nominal time, and requires an explicit OFF or FLEXIBLE choice. A 15-minute window for an 08:30 occurrence permits initial invocation later within that window. It does not reserve the remaining minutes for application processing or establish that the brief will be accepted before 09:00.

The application owner should compare the earliest and latest allowed dispatch with queueing, execution, validation and publication. If no defensible completion margin remains, narrow the allowed dispersion, move the nominal occurrence earlier or change the completion objective. A schedule with its window turned off still needs realistic execution and failure allowances. Clock precision is one input to the deadline review, not the deadline itself.

Record both the intended local date and resolved UTC time. Calculate delay from the intended occurrence, rather than from the most recent retry or worker start. Otherwise a job first due at 08:30 and received at 09:04 can look punctual merely because the worker finished two minutes after starting.

The cutoff policy must choose what happens to late work. For this internal brief, the illustrative policy holds publication and notifies the report owner after the cutoff. The owner may approve a clearly labeled late version after checking whether a newer brief or manual result already exists. Another job may safely supersede older work, while a financial instruction may require a different response. Those dispositions belong to the business contract and cannot be inferred from the presence of a retry policy.

Illustrative FLEXIBLE-window example for brief-west on 19 October 2026 in America/Los_Angeles. The dispatch and acceptance times are synthetic, not measured AWS timings. The 09:00 cutoff is an application rule; acceptance also requires the agreed output, scope and receipt. This is separate from the later filled OFF-window fixture.

The FLEXIBLE-window example is synthetic and separate from the later OFF-window record. The application owns acceptance and the exclusive 09:00 cutoff. Retries do not reset the intended occurrence or its deadline.

4. Read back the configuration that implements the contract

Prepare a configuration review before an authorized implementation. Record the schedule account, Region, group, name and returned ARN, plus a dated configuration snapshot or digest. Include the exact target operation and its input revision. A familiar schedule name alone does not establish which target or timezone is active.

The CreateSchedule reference describes StartDate and EndDate as UTC boundaries for recurring schedules, with actual occurrences depending on the expression. It ignores those fields for one-time schedules. It also defines enabled/disabled state and ActionAfterCompletion. A created schedule ARN establishes a control-plane result, not a delivered or accepted report. CreateSchedule request and response.

Treat the API's ClientToken as creation-request idempotency. It is not a business-operation identifier that prevents a downstream duplicate publication. Keep it in the configuration change record while the application uses its own occurrence and effect identities. For one-time schedules, agree whether ActionAfterCompletion should be DELETE and where the configuration evidence will remain after deletion. Do not interpret schedule cleanup as deletion of queued work, logs or business effects.

The Target API identifies the target ARN, execution role, input, retry policy and optional dead-letter configuration. Read those fields together. Ask the authorized cloud owner to verify that the role can perform the intended target action and cannot reach an unintended destination. This guide supplies no account credentials, deployable permission policy or claim of tested least privilege.

A denied configuration read leaves evidence unknown. It does not establish that a retry setting, collector or schedule is absent. If the schedule definition changes during review, take a new snapshot and regenerate the affected expectations. Never join the old timezone to the new target and describe the combined record as the deployed configuration.

5. Keep delivery attempts separate from accepted work

AWS describes Scheduler as providing at-least-once target delivery. Design the application to recognize repeated attempts rather than assuming one visible occurrence permits only one effect. Scheduler features. The completion record still needs to establish which business result was accepted and whether it was published to the intended recipient.

The RetryPolicy API bounds delivery retry attempts and event age. Its documented ranges are zero through 185 retries and 60 through 86,400 seconds for maximum event age. Retrying uses exponential backoff until an applicable limit is reached. Record the actual values. Do not add a flexible window, maximum event age and worker timeout into a fabricated guaranteed completion time.

For an illustrative manifest, choose 1,800 seconds and three retries for delivery review, with the independent 09:00 application cutoff still enforced. These values are invented inputs for discussion, not a recommendation for every brief. An event can arrive before the cutoff and finish afterward. The publisher must check the business rule at the effect boundary, with an agreed treatment of a result whose publication time is uncertain.

Scheduler can add context for schedule ARN, scheduled time, execution ID and attempt number to target input. The context-attributes guide defines the execution ID per attempted target invocation. Preserve the scheduled time and configuration identity through any permitted transformation. A new execution ID is not proof of a new business occurrence.

The schedule ARN and those native context fields do not identify an immutable configuration revision. Include an application-controlled contract/input revision in the reviewed target payload and retain the corresponding definition and authorized change record. That revision label is an application field, not another Scheduler substitution or independent proof of trust. Validate it through the target's approved caller and configuration path. Do not attach an old attempt to the currently returned definition just because the schedule ARN matches.

For a counterexample, stipulate that an attempt carrying revision v1 is delayed while the schedule is changed to v2. When it arrives, compare its v1 reference with the retained v1 definition and the current authority for its intended effect. Do not assume that updating the schedule rewrote, recalled or reauthorized already-dispatched work. If the revision is missing, conflicting or cannot be validated, retain UNKNOWN and hold the consequential effect for reconciliation. A timestamp near the change is not a substitute for the missing binding.

For this example, the application assigns one occurrence key from the business job and intended local date, retaining the contract revision alongside it as provenance. A configuration edit must not create authority to publish a second brief for that same date. This key fits a contract allowing one brief per business date. An hourly job needs a different key, and a corrected reissue needs an explicit version relationship and approval. A worker must validate the received context against approved configuration and scope before using it to authorize an effect.

Consider three proposed failure fixtures. A duplicate arrives after the first brief was accepted: look up the occurrence and verify the existing result instead of publishing another copy. A response is lost after publication: mark the effect uncertain and reconcile the destination before retrying. A delayed attempt arrives after 09:00 with no existing result: hold it under the late-work policy. Retention must cover the accepted retry and recovery horizon; deleting the occurrence record too early can make an old duplicate look new.

6. Keep an inspectable recurrence and evidence manifest

The manifest is an application review artifact, not an AWS request schema. Keep sensitive ARNs and receiver identifiers in approved storage, and use safe references in a shareable review. Each actual occurrence should link back to one configuration revision. Preserve a calendar skip, a delivery failure, held work and accepted work as different dispositions.

Contract identity

Record and validation question: Business job, revision, owner and the accepted-result definition

Scheduler identity

Record and validation question: Account/Region, group/name/ARN and dated configuration reference

Recurrence

Record and validation question: Exact expression, IANA timezone, applicable start/end boundaries and enabled state

Calendar basis

Record and validation question: Local parser/version, pinned timezone data and digest; AWS data version or UNKNOWN

Intended occurrence

Record and validation question: Local date/time, possible UTC mapping, resolved mapping evidence and occurrence key

Calendar exceptions

Record and validation question: Gap, repeated-time, holiday and missed-occurrence policy with decision owner

Dispatch policy

Record and validation question: Explicit flexible-window mode/size and actual delivery retry age/attempt limits

Target authority

Record and validation question: Operation, application-controlled contract/input revision, retained definition/change evidence, execution role and allowed destination evidence

Delivery evidence

Record and validation question: Scheduled time, attempt identity/number, target response reference and limitations

Business cutoff

Record and validation question: Exact local/UTC boundary, inclusive/exclusive rule and late-work disposition

Effect evidence

Record and validation question: Application job, durable effect identity, destination receipt and uncertainty state

Accepted result

Record and validation question: Output reference, validation evidence, recipient scope and acceptance time or UNKNOWN

Recovery

Record and validation question: Stop owner, pending-work inventory, reconciliation owner and selective restart decision

A completed fictional example is brief-west/v1, a weekday 08:30 Los Angeles cron schedule. Its occurrence on 19 October 2026 corresponds to 15:30 UTC under the pinned reference rules. The business cutoff is 09:00 local, or 16:00 UTC, exclusive. Flexible dispatch is off, while delivery age and retries use the illustrative settings above. The invented attempt reaches the worker at 15:36 UTC; its accepted output is recorded at 15:42 UTC. With matching scope and receipt references stipulated, the application disposition is accepted before cutoff.

Those invented timestamps do not measure AWS precision or latency. In a second version of the same fixture, the output reference is missing. Keep business acceptance UNKNOWN despite the target response. In a third, publication is recorded at exactly 16:00 UTC. Classify it as late under this example's exclusive boundary, then apply the hold/reconciliation decision. A manifest that changes its cutoff rule after seeing the result cannot support an honest acceptance decision.

7. Rehearse exceptions and assign stop and recovery owners

Use permitted synthetic inputs and a non-delivering test sink when an authorized rehearsal is commissioned. The business owner specifies expected dispositions before the test. The cloud owner owns schedule configuration and target authority; the application owner owns occurrence validation, duplicate handling and result reconciliation. An operator owns the alert route and the decision to stop dispatch. One person can hold several roles, but the manifest must identify who can act when that person is unavailable.

Exercise S1 through N1 as calendar fixtures, then the delayed, duplicate and uncertain-effect paths. Add a disabled interval that spans a due occurrence, a configuration change close to the boundary, an unavailable collector and a worker still processing when the next occurrence becomes due. The required output is a scoped disposition and evidence reference for each case. A console schedule preview or successful local conversion covers only its own calculation.

For a skipped occurrence, separate a documented DST gap from an outage or disabled interval. Do not claim universal catch-up after re-enabling. Compare intended occurrences with retained delivery and application records, classify the missing evidence, and let the owner decide whether a make-up occurrence remains useful and permitted. Its identity should refer to the original work and explain why a new dispatch will not duplicate a manual result.

AWS documents that changing state uses UpdateSchedule, which requires the full required configuration and can reset previously set fields that are omitted. Use an authorized change procedure that preserves the reviewed definition, then verify the resulting state. Changing a schedule's state. This guide does not include a partial update command that could accidentally alter the target or window.

Treat a disable action as one containment control. Separately inspect already delivered, queued or in-flight work and enforce the application stop boundary. Do not infer that a configuration update recalled a sent request. Preserve collector access and occurrence records while their owner reconciles unknown effects. The Scheduler management guide describes a standard SQS DLQ for failed target delivery after retry exhaustion; an empty collector cannot establish accepted business completion.

Restart with an explicit selection of still-authorized occurrences. Check the cutoff, manual substitutions, recipient scope and prior effects again. If the original reporting period has closed, an audited skip or a separately approved correction can be safer than processing everything that accumulated. Record that decision and retain the evidence needed to explain the missing or replaced result.

8. Close the recurrence decision before enabling production

Local-time cron fits a civil-calendar requirement when its documented gap and repeat policies are acceptable. A rate expression fits an elapsed-duration requirement with a known anchor. Resolved one-time occurrences can fit exceptions requiring explicit approval of each instant, but their producer must own timezone interpretation, duplicates, creation failures and cleanup. Materializing one-time schedules moves calendar decisions into that producer; it does not remove them.

If the job depends on a changing holiday calendar, completion-relative intervals or linked business steps, compare an application calendar service or a workflow design against the same accepted-result rule. Avoid constructing a large schedule producer merely to work around an unagreed meaning of “daily.” Conversely, do not keep a small cron expression when the owner needs a business calendar it cannot express by itself.

As the next step, take one actual requirement and complete the blank manifest before asking for implementation. Resolve whether a missing spring occurrence is acceptable, how a repeated local label is represented, and what late work may still do. Identify the evidence owner for every UNKNOWN and the approved environment for the first rehearsal. Enable production only through the team's authorized release process after the relevant calendar, authority, effect and recovery evidence has been reviewed. Keep the accepted manifest with the configuration so the next timezone or business-rule change starts from the decision that was made.