agent's instance scheduler broke on daylight saving, the stop cron ran an hour early and killed the morning batch

TL;DR

Cron expressions have no timezone memory. Express every start/stop schedule in UTC, or use the scheduler's timezone field with an IANA name, and test the schedule against the next DST transition. One hour of drift is the difference between "stopped overnight" and "killed the morning batch."

agent's instance scheduler broke on daylight saving, the stop cron ran an hour early and killed the morning batch

Use this when

• Start/stop rules fired an hour early or late around a daylight saving change.
• The schedule uses a cron expression with no explicit timezone.
• A batch job or build window got caught by a shifted stop.

Not for this skill when

• The schedule already specifies a timezone or runs in UTC. Look for a different cause.
• The shift is larger than an hour or happens at other times. That is a different bug.

Steps

1. Check how the schedule expresses time: EventBridge rule, EventBridge Scheduler, or cron on an instance. Verify: find the expression and whether a timezone is set.
2. Convert the intended local times to UTC and rewrite the cron in UTC, or set the scheduler's Timezone field to the IANA name (e.g. America/New_York) if the service supports it.
3. For EventBridge Scheduler, set the timezone field explicitly; for classic EventBridge rules, cron is UTC-only, so convert.
4. Compute the next two DST transitions for the region and verify the UTC-converted schedule still lands inside the intended window on both sides.
5. Run the next stop/start cycle and confirm the batch window was untouched.
6. Document the chosen convention (all schedules in UTC) so the next automation does not reintroduce local time.

Variant phrasings

eventbridge schedule daylight saving time shift

The AWS-specific phrasing.

cron ran an hour early after dst change

Symptom-level search.

instance scheduler timezone wrong

The configuration framing.

Compatibility: EventBridge Scheduler supports timezones; classic EventBridge rules are UTC-only. Instance-level cron uses system time.

Why it happens

Agents write cron in the timezone they are thinking in and deploy it to a service that reads UTC, or they set a local-time cron on an instance whose system clock follows DST. Twice a year the mapping shifts by an hour and the stop lands inside a live window.

Edge cases / pitfalls

• Regions that do not observe DST (Arizona, most of Asia) never see this; do not "fix" those schedules into a new bug.
• If the batch window itself is defined in local time, converting the stop to UTC without converting the batch window reintroduces the same mismatch.
• EventBridge Scheduler timezone support is the clean fix; rewriting everything to UTC is the portable one. Pick one convention per org.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-PXtNx6EfjShScTIEeUzfg