What is the cron expression for every day at 11pm?

The cron expression for every day at 11pm is "0 23 * * *". Runs once a day at 11pm, every day.

What should I watch out for when running a cron job every day at 11pm?

11pm is 23:00, the last hour before the date flips. 0 23 * * * — 0 11 * * * is 11am. At this hour the date-boundary risk is real: a job that starts at 23:00 but stamps rows with the time it finishes can write tomorrow's date if it runs past midnight. Overrunning past midnight means colliding head-on with the 0 0 * * * job swarm. Backups, logrotate, and cron's own daily housekeeping all fire at 00:00; an 11pm job that bleeds over fights them for I/O and may itself be starved. Keep it short, or move heavy work earlier in the evening.

Cron expression for Every day at 11pm

0 23 * * *

Runs once a day at 11pm, every day.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `0 23 * * *`

Running a last pre-midnight job that must still be attributed to today's date before the calendar rolls over
Capturing the most complete daily snapshot possible while still finishing before the midnight maintenance crunch
Triggering a nightly export timed so a downstream partner's midnight ingestion finds the file already in place

Use `0 23 * * *` on your platform

It’s the same 5-field expression everywhere — what changes is where you put it and which timezone it runs in.

Linux / crontab

0 23 * * * /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

on:
  schedule:
    - cron: "0 23 * * *"

GitHub Actions always runs scheduled jobs in UTC — there is no timezone setting, and runs can be delayed under load (official docs).

Kubernetes CronJob

spec:
  schedule: "0 23 * * *"

Defaults to UTC. Set spec.timeZone (Kubernetes 1.27+) for a specific zone — see the CronJob docs.

Quartz / Spring `@Scheduled`

Quartz uses 6 fields (seconds first): 0 0 23 * * *. Watch out: Quartz day-of-week is 1=SUN … 7=SAT (not 0–6), and day-of-month / day-of-week use ? — double-check if your schedule touches those fields (Quartz cron reference).

Gotchas with every day at 11pm schedules

11pm is 23:00, the last hour before the date flips. 0 23 * * * — 0 11 * * * is 11am. At this hour the date-boundary risk is real: a job that starts at 23:00 but stamps rows with the time it finishes can write tomorrow's date if it runs past midnight.
Overrunning past midnight means colliding head-on with the 0 0 * * * job swarm. Backups, logrotate, and cron's own daily housekeeping all fire at 00:00; an 11pm job that bleeds over fights them for I/O and may itself be starved. Keep it short, or move heavy work earlier in the evening.
A 23:00 job on a UTC box can land on the wrong calendar day for local users. 11pm UTC is already past midnight in Central Europe and well into "tomorrow" further east, so your "today's snapshot" quietly includes or excludes the wrong day. Pin CRON_TZ to the timezone your date logic assumes.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `0 23 * * *` the right schedule?

If the job doesn't truly need to beat midnight, every day at midnight aligns cleanly with the date rollover and avoids the "finished after midnight, wrong date" bug — but you then share the 00:00 contention window.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: