Every Day at 1 AM Cron Expression
Runs once daily at 01:00 server time.
0 1 * * * in POSIX cron
Expression
0 1 * * *Try it in the tester →Field Breakdown
How It Works
Fires at 01:00 every day — a common slot for off-peak batch jobs after the midnight wave has cleared.
Example Run Times
- Mon 01:00:00
- Tue 01:00:00
- Wed 01:00:00
- Thu 01:00:00
- Fri 01:00:00
Frequently Asked Questions
Why pick 1 AM instead of midnight?
Lots of systems pile work onto `0 0 * * *`. Shifting to 01:00 spreads load and side-steps DST fall-back ambiguity around 00:00.
0 1 * * * in Quartz / Spring
One run per day at 01:00:00 — an hour past midnight, after the dense wave of 00:00 jobs has come and gone. For schedulers hosting many nightly tasks, 1 AM is effectively the second seating.
Quartz / Spring expression
0 0 1 * * ?Try it in the tester →At 01:00:00
Unix / POSIX equivalent: 0 1 * * *
Field Breakdown
Using It with Quartz / Spring
The 01:00 slot inherits everything that wants to be nightly but shouldn't fight the midnight stampede: archiving yesterday's rows once the day-close jobs have committed, deduplication sweeps over the day's ingested data, or pre-rendering reports that humans will open at 09:00. Spring schedules it with @Scheduled(cron = "0 0 1 * * ?"); Quartz with the equivalent CronTrigger. Sequencing is the main design concern — if this job consumes what a midnight job produces, an hour of headroom is an assumption, not a guarantee, so verify the upstream job's worst-case duration or chain the jobs explicitly.
Quartz-Specific Notes
- →In US zones the fall-back transition replays the 01:00-01:59 wall-clock hour, but the trigger still fires once that night — Quartz computes discrete fire times rather than re-matching every wall-clock minute.
- →Spring-forward (02:00 jumping to 03:00 in those same zones) never touches 01:00, so this schedule keeps all 365 firings through both transitions.
- →Hour 1 is the third field; the two zeros before it are seconds and minutes, so the firing is 01:00:00 sharp rather than "sometime during the 1 AM hour."
Frequently Asked Questions
Does the job run twice on the night clocks fall back?
No. Even though 01:00 appears twice on the wall clock that night in affected zones, the CronTrigger has a single scheduled fire time for the date and executes once.
Why schedule at 1 AM rather than midnight?
Midnight is the most oversubscribed minute in most schedulers — day-close, rollover, and default-configured jobs all land there. An hour's offset gives the same nightly semantics with less contention for threads, database locks, and downstream APIs.
How do I nudge this to 01:15?
Set the minute field: 0 15 1 * * ? fires daily at 01:15:00. Only the middle time field changes; the daily cadence and the ? placement stay as they are.
0 1 * * * in AWS EventBridge
One run per day at 01:00 UTC. Schedulers worldwide are busiest at the stroke of midnight, so pushing a nightly job one hour later is a cheap way to keep it clear of the rush of jobs, certificate renewals, and batch windows that all pile onto 00:00.
AWS EventBridge expression
cron(0 1 * * ? *)Try it in the tester →At 01:00 UTC
Unix / POSIX equivalent: 0 1 * * *
Field Breakdown
Using It with AWS EventBridge
The 01:00 UTC slot suits second-wave nightly work: jobs that consume the output of a midnight run, database exports that should start after midnight log rotation completes, or report builders that need the previous UTC day fully closed before reading it. Configure the expression on a rule targeting Lambda, ECS, or Step Functions as the job demands. If the dependency on a midnight predecessor is real rather than incidental, consider replacing the fixed one-hour gap with a Step Functions workflow that runs both stages in sequence — a slow midnight job will not politely finish by 01:00 just because the schedule assumes it.
AWS-Specific Notes
- →01:00 UTC is 8 or 9 PM US Eastern the previous evening and a fixed 10:00 in Tokyo, Japan having no DST to shift it.
- →By 01:00 UTC the previous UTC day is a full hour closed, giving late-arriving events time to land before a daily aggregate reads them.
- →Chaining nightly jobs by spacing their hours is fragile under at-least-once, possibly-late delivery; explicit orchestration expresses the dependency directly.
Frequently Asked Questions
Why schedule at 1 AM instead of midnight?
Two common reasons: avoiding the global midnight thundering herd of scheduled jobs, and letting midnight-anchored processes — log rotation, day-close aggregation, certificate renewals — finish before this job reads their output.
How do I get 1 AM in my own timezone rather than UTC?
Classic rules cannot do it; they are UTC-only. Create the schedule in EventBridge Scheduler, keep the same cron body, and set ScheduleExpressionTimezone to your IANA zone — the 01:00 then tracks local clock changes automatically.
0 1 * * * in GitHub Actions
One run daily at 01:00 UTC — a deliberate sidestep. Midnight UTC is likely the most contested scheduling instant on GitHub Actions (delays are documented to be worst at the top of the hour, and 00:00 is the default reflex for nightly jobs), and moving a nightly job just one hour later removes it from that pile-up while changing essentially nothing about what the job does.
GitHub Actions expression
0 1 * * *Try it in the tester →At 01:00 UTC
Unix / POSIX equivalent: 0 1 * * *
Field Breakdown
Using It with GitHub Actions
As on: schedule: - cron: "0 1 * * *" in workflow YAML on the default branch, the 1am slot carries the same workloads people reflexively put at midnight — backups, nightly report generation, artifact cleanup, batch recomputation — for jobs where the exact hour is irrelevant. GitHub documents that scheduled delivery is delayed worst at the top of the hour, so the fully defensive version also moves off minute zero: "17 1 * * *" keeps the nightly rhythm while avoiding both the day-boundary spike and the hourly one.
GitHub-Specific Notes
- →By 01:00 UTC the date boundary is an hour behind, so "yesterday" computed in the job is unambiguous even if the run starts several minutes late — a practical edge over exactly-midnight schedules for date-partitioned work.
- →Local equivalents: 20:00 the previous evening in New York under EST, 02:00 in central Europe in winter, and a constant 10:00 in Tokyo.
- →The hour shift is free — nothing downstream of a nightly job can usually tell whether it ran at 00:00 or 01:00 UTC, making this one of the cheapest reliability improvements available to a schedule.
Frequently Asked Questions
Is 1am UTC really better than midnight for a scheduled workflow?
For start-time punctuality, generally yes: GitHub documents that scheduled runs are delayed most at the top of the hour, and 00:00 UTC plausibly attracts the largest share of nightly jobs. 01:00 — better yet with a non-zero minute like 17 — requests a far less contested instant.
My job needs the previous day's complete data — is 01:00 UTC safe?
If the upstream finalizes its day on UTC, yes: you have a full hour of margin past the boundary. If it finalizes on some local day, convert that closing time to UTC and schedule after it — the 01:00 anchor only protects you against the UTC rollover.