Every Day at 3 AM Cron Expression
Runs once daily at 03:00 — the classic backup window.
0 3 * * * in POSIX cron
Expression
0 3 * * *Try it in the tester →Field Breakdown
How It Works
Fires at 03:00 every day — the canonical window for nightly backups, log rotations, and reindex jobs.
Example Run Times
- Mon 03:00:00
- Tue 03:00:00
- Wed 03:00:00
- Thu 03:00:00
- Fri 03:00:00
Frequently Asked Questions
Why is 3 AM so common for backups?
Traffic is at its overnight minimum and DST transitions have completed, so the wall clock and elapsed time match up cleanly.
0 3 * * * in Quartz / Spring
Daily at 03:00:00 — the hour that decades of operations practice turned into the default maintenance window. Traffic is at its trough, the midnight and 1 AM batch waves have finished, and in most zones the DST drama of the 01:00-03:00 band has already played out by the time this fires.
Quartz / Spring expression
0 0 3 * * ?Try it in the tester →At 03:00:00
Unix / POSIX equivalent: 0 3 * * *
Field Breakdown
Using It with Quartz / Spring
This is where the heavy nightly machinery runs: full database dumps, log rotation and compression, search-index rebuilds, and table-statistics refreshes that would degrade performance if run under load. Bind it with @Scheduled(cron = "0 0 3 * * ?") in Spring or a CronTrigger in Quartz, and give the job a generous-but-monitored runtime budget — a backup that creeps past sunrise defeats the purpose of the quiet window. Where many services share one database, stagger their 3 AM jobs by minutes (0 0 3, 0 20 3, 0 40 3) so they don't all snapshot the same instance simultaneously.
Quartz-Specific Notes
- →In zones that shift clocks within the 01:00-03:00 band, 03:00 exists on both transition nights: spring-forward lands the clock on (or past) 03:00 at the jump, and fall-back replays only earlier hours — so the backup fires every night of the year there.
- →The quiet-window assumption is a local-time argument; on a JVM defaulting to UTC, "03:00" may be peak evening for your actual users. Pin the zone that matches your traffic curve.
- →With one firing per day, an overrun colliding with the next execution would require a 24-hour job — runtime alerting matters here more than concurrency guards.
Frequently Asked Questions
My 3 AM backup started running at a different local hour after we containerized — why?
The new container's JVM default timezone almost certainly changed (commonly to UTC). Quartz evaluates the hour field against the trigger's zone, so pin it: zone = "America/Denver" on @Scheduled or inTimeZone(...) on the Quartz schedule builder.
Is 3 AM actually safe from daylight-saving anomalies?
In zones transitioning between 01:00 and 03:00 — including the US and EU patterns — yes: the 03:00 fire time is never inside a skipped or repeated interval there. Zones with unusual transition times exist, so check yours if it's exotic.
What if the backup occasionally takes more than an hour?
Nothing collides — the next firing is 24 hours out, not an hour out. The real risks are finishing after traffic ramps up and masking slow growth in backup duration, so alert on completion time rather than relying on the schedule for safety.
0 3 * * * in AWS EventBridge
A daily firing at 03:00 UTC, the hour cron folklore reserves for backups — late enough that midnight processing has settled, early enough to finish before anyone's morning. On EventBridge the slot is defined in UTC, so check whose 3 AM you are actually getting before trusting the folklore.
AWS EventBridge expression
cron(0 3 * * ? *)Try it in the tester →At 03:00 UTC
Unix / POSIX equivalent: 0 3 * * *
Field Breakdown
Using It with AWS EventBridge
This rule most often fronts heavyweight nightly maintenance: triggering RDS or EBS snapshot workflows, launching an ECS task that rebuilds a search index, compacting data-lake partitions, or running integrity checks across object stores. Hand the expression to PutRule or define it in CDK, and prefer Step Functions as the target when the maintenance has ordered steps and needs retry semantics. For a US-serving system, note that 03:00 UTC is actually late evening Eastern — prime time for some consumer workloads — whereas a Europe-serving system genuinely gets the dead of night.
AWS-Specific Notes
- →03:00 UTC equals 10 or 11 PM US Eastern the prior evening, 04:00 or 05:00 in central Europe, and exactly noon in Tokyo year-round.
- →Snapshot-style jobs triggered here should tolerate a duplicate trigger: at-least-once delivery makes the second snapshot request the target's problem to deduplicate.
- →If the job must run at 3 AM local time in a DST-observing region, an EventBridge Scheduler schedule with a timezone is the supported route; a UTC rule will slip an hour twice a year.
Frequently Asked Questions
Is 3 AM UTC actually a quiet window for my system?
Only your traffic data can say. It is nighttime for Europe and Africa, but late evening in the Americas and the middle of the workday in East Asia. Pick the hour from your own CloudWatch request curves rather than inherited crontab habit.
My backup at 3 AM sometimes starts a minute or two late — is that a problem?
It is expected behavior. EventBridge aims for the scheduled minute but may invoke up to a minute late under load, and the target adds its own cold-start or queue latency. Treat the schedule as approximately 03:00, not a hard real-time deadline.
Can the same rule also kick off a verification job after the backup?
A rule supports up to five targets, but they all fire at 03:00 in parallel — there is no ordering between them. For backup-then-verify sequencing, target a Step Functions state machine that runs the two stages in order with retries.
0 3 * * * in GitHub Actions
The classic sysadmin maintenance hour, ported to a platform where the clock is UTC-only: one run daily at 03:00 UTC. Whether that is actually the middle of anyone's night depends entirely on where your users are — it is lunchtime in Tokyo.
GitHub Actions expression
0 3 * * *Try it in the tester →At 03:00 UTC
Unix / POSIX equivalent: 0 3 * * *
Field Breakdown
Using It with GitHub Actions
Written as on: schedule: - cron: "0 3 * * *" in a workflow on the default branch, the 3am slot inherits the workloads tradition assigns it: database dumps pushed to cloud storage or a backup branch, log compaction, full-text search reindexing, and other jobs you'd rather run while a particular audience sleeps. For Europe the instinct holds — 03:00 UTC is 04:00 or 05:00 across the continent — but verify the assumption against the timezones that matter to your project before relying on the quiet-hours framing.
GitHub-Specific Notes
- →03:00 UTC is 22:00 the previous evening in New York under EST, 04:00 in central Europe in winter, and exactly 12:00 in Tokyo every day of the year — Japan has no daylight saving, so the JST lunch-hour collision is permanent.
- →Pick the hour by your audience's UTC offsets rather than the 3am folklore; on a UTC-only scheduler the number 3 carries none of its crontab-on-a-local-server meaning.
- →A daily run that uploads an artifact accumulates roughly 90 of them at the default 90-day artifact retention before old ones age out — set retention-days explicitly if the dumps are large.
Frequently Asked Questions
Why does my 3am maintenance job interrupt the Tokyo team's workday?
Because 03:00 UTC is 12:00 JST — midday, not night. To run during Japan's small hours instead, schedule around 17:00 UTC: "0 17 * * *" lands at 02:00 JST, and Japan's lack of daylight saving keeps it there permanently.
Is 3am UTC a quieter time for the Actions scheduler than other hours?
GitHub publishes no per-hour load data, so there is no documented basis for picking 3am over any other hour. What is documented is that delays are worst at the top of the hour — offsetting the minute field does more for punctuality than guessing at a quiet hour.