Context
A request to run a job “every morning” contains a business calendar assumption. EventBridge Scheduler supports cron, rate and one-time expressions, and those choices behave differently around time-zone changes. Define the intended wall-clock behavior before writing an expression. A schedule firing successfully is also separate from the target finishing its work.
Capture the scheduling contract
Record the schedule name and group, expression, time zone, start and end boundaries, flexible window, target ARN, execution role and retry settings. Ask the workload owner to specify a local time or an elapsed interval, plus the intended behavior when that local time does not occur.
Use an IANA time-zone identifier supported by Scheduler rather than an informal abbreviation. Keep business-date calculation inside the target explicit as well: a job triggered for a local morning may otherwise label its output with the wrong UTC date.
1. Choose cron or rate deliberately
Use cron when the requirement is a recurring wall-clock time in a named zone. Use a rate when the requirement is an elapsed duration. AWS documents that days in a rate expression represents twenty-four hours, so it is not automatically equivalent to the same local time on every calendar day.
For a one-time schedule, record the date and configured time zone together. Review activation boundaries when replacing a schedule so both old and new definitions do not unintentionally cover the same business period.
2. Review daylight-saving and delivery windows
AWS documents that a cron occurrence in a nonexistent spring-forward local time is skipped. A repeated fall-back local time invokes only once. Decide whether those rules satisfy the business requirement; if a skipped occurrence needs compensating work, make that reconciliation explicit.
Inspect the flexible time window. A configured window intentionally allows invocation within an interval, so an observed delay inside that interval is not necessarily a delivery defect. Separate the scheduling window from queueing or processing delay in the target.
3. Compare configuration with timestamp evidence
| Evidence | Explanation to test | Next check |
|---|---|---|
| Local run time shifts after DST | Rate used for wall-clock requirement | Expression and time zone |
| One spring occurrence is absent | Cron time did not exist locally | DST rule and business reconciliation |
| Invocation occurs later within a window | Flexible scheduling is enabled | Window configuration |
| Invocation succeeds but report is missing | Target accepted but work failed | Completion ledger and target logs |
An explicitly illustrative scenario: a finance export must run at the start of a local workday. Its original rate schedule maintains an elapsed interval, so the local delivery time changes across the seasonal clock transition. The owner replaces it with a reviewed local-zone cron expression and defines a completion record keyed by business date. A separate check identifies any date whose export was never completed.
Verify future behavior and operational recovery
Read back the saved schedule through GetSchedule and compare every timing field with the approved contract. In a test environment, use short-lived schedules to verify the target payload, intended role and completion evidence. Review future DST boundary dates against the documented rules without claiming that a short live test reproduces every seasonal transition.
The SOP should document time zone, calendar owner, flexible-window rationale, idempotency key and handling of missed business periods. Monitor invocation failures and target completion separately. When teams change local operating hours or jurisdictions, review the schedule and business-date logic together. This prevents a correct scheduling expression from producing an incorrectly labelled or missing business result.
Explore Clouvenix cloud architecture for implementation and operational handover.
Technical reference
Scheduler schedule types, GetSchedule fields, and flexible-window setup define timing behavior.