Every Day at 11 PM Cron Expression
Runs once daily at 23:00 — late-night slot before the midnight wave.
0 23 * * * in POSIX cron
Expression
0 23 * * *Try it in the tester →Field Breakdown
How It Works
Fires at 23:00 every day — useful when you need to finish before the midnight backup window kicks in.
Example Run Times
- Mon 23:00:00
- Tue 23:00:00
- Wed 23:00:00
- Thu 23:00:00
- Fri 23:00:00
Frequently Asked Questions
What's the latest hour cron accepts?
Hour values range from 0 to 23. There is no hour 24 — midnight is hour 0 of the next day.
0 23 * * * in Quartz / Spring
The last full hour of the calendar day: one firing at 23:00, every day. It exists for work that must be finished — not merely started — before midnight flips the date and the heavyweight nightly window begins.
Quartz / Spring expression
0 0 23 * * ?Try it in the tester →At 23:00:00
Unix / POSIX equivalent: 0 23 * * *
Field Breakdown
Using It with Quartz / Spring
Pre-midnight jobs do the prep work the 00:00 wave depends on: flushing buffered events so the nightly aggregate sees complete data, expiring same-day promotions, or closing out a business date in systems where the date boundary is meaningful. Spring picks it up via @Scheduled(cron = "0 0 23 * * ?"); Quartz via a CronTrigger. The one-hour runway to midnight is this schedule's entire reason for existing, so instrument the duration — the day this job takes 61 minutes is the day your midnight batch processes half-finished data.
Quartz-Specific Notes
- →Cron controls start times only; nothing in Quartz stops an execution at midnight. If finishing before 00:00 is a hard requirement, the job itself needs a deadline check or timeout.
- →A run that does cross midnight will see LocalDate.now() change mid-execution — capture the working date once at the top of the job rather than re-reading the clock.
- →Quartz misfire handling matters here: with the default smart policy, a scheduler that was down at 23:00 fires the trigger once on restart, even if that lands after midnight when the job's premise no longer holds. MISFIRE_INSTRUCTION_DO_NOTHING is often the safer choice for date-boundary work.
Frequently Asked Questions
Why 23 and not 11 in the hour field?
Quartz hours run 0-23. An 11 would fire at 11:00 in the morning; 23 is the only spelling of 11 PM.
Can Quartz guarantee my job completes before midnight?
No scheduler can — it controls when execution begins, not how long it takes. Budget the runway: if the job ever approaches an hour, either start earlier (0 0 22 * * ?) or make it date-aware so a midnight crossing is handled, not hoped against.
0 23 * * * in AWS EventBridge
This rule claims the final hour of the UTC day, firing at 23:00 with exactly sixty minutes of runway before the date rolls over. It exists for work that must complete inside today — snapshotting, finalizing, sealing — before midnight jobs start reading what it wrote.
AWS EventBridge expression
cron(0 23 * * ? *)Try it in the tester →At 23:00 UTC
Unix / POSIX equivalent: 0 23 * * *
Field Breakdown
Using It with AWS EventBridge
Register it through aws events put-rule and attach the pre-midnight workload with put-targets: a Lambda that freezes the day's metric counters into an immutable daily record, a Step Functions run that reconciles today's orders against payments while both still say the same date, or a final EBS snapshot taken ahead of the overnight maintenance window. The defining design constraint is the 60-minute budget — if the job cannot reliably finish by 23:59, it belongs at an earlier hour or needs to be split so only the fast sealing step runs here.
AWS-Specific Notes
- →Everything this job stamps with the current date still reads today, unlike a 00:05 job that wakes up in tomorrow — a subtle but common source of off-by-one-day bugs in daily reporting.
- →23:00 UTC is 18:00 or 19:00 US Eastern and already 08:00 the next morning in Tokyo, where the previous day closed nine hours earlier.
- →The 23:00 slot is noticeably quieter than 00:00 UTC, which concentrates an outsized share of the world's scheduled jobs.
Frequently Asked Questions
The job occasionally finishes after midnight — does it corrupt the date logic?
Only if the code calls now() for its date. Derive the working date from the time field of the triggering event instead; it always reads 23:00 on the intended day no matter when execution completes.
Why schedule at 23:00 rather than just after midnight?
Two reasons: the writes land while the calendar date still matches the data being sealed, and the midnight jobs that consume the sealed output get a guaranteed head start of one hour rather than racing the producer.
0 23 * * * in GitHub Actions
The last scheduled hour of the UTC day: one run at 23:00, leaving a 60-minute buffer before the date flips. Teams pick this slot precisely because the output gets stamped with the day it summarizes, rather than landing a minute into tomorrow.
GitHub Actions expression
0 23 * * *Try it in the tester →At 23:00 UTC
Unix / POSIX equivalent: 0 23 * * *
Field Breakdown
Using It with GitHub Actions
As on: schedule: - cron: "0 23 * * *" in workflow YAML, the 23:00 slot suits closing-the-books work: snapshotting metrics while the UTC date is still current, pushing the day's accumulated logs to long-term storage, or sweeping temporary branches and stale deployments before midnight pipelines begin elsewhere. It is also a sensible last call for anything that must complete before a separate 00:00 process consumes its output. For US audiences the timing is friendlier than it sounds — 23:00 UTC is 6:00 or 7:00 PM Eastern, genuinely end-of-day there too.
GitHub-Specific Notes
- →If the job derives "today" from its own start time, a delayed start that slips past midnight UTC would mislabel the whole run — compute the target date from the intended schedule, not from the clock at runtime.
- →23:00 UTC is 18:00 or 19:00 in New York but already 08:00 the next morning in Tokyo, so an end-of-day framing only holds west of UTC.
- →This run and a separate midnight workflow are fully independent — a 90-minute job here does not delay or block anything scheduled at 00:00.
Frequently Asked Questions
Why schedule end-of-day work at 23:00 instead of midnight?
At 23:00 the UTC calendar date is still the day being summarized, so file names, commit messages, and report titles come out right with no date arithmetic. A midnight run is technically summarizing yesterday and has to subtract a day everywhere.
Is one hour enough margin before midnight?
For the start time, usually — typical scheduling delay is minutes, not an hour. But a long-running job can still be executing past 00:00; that is fine as long as it captured its dates at the start rather than reading the clock late in the run.