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

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

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

10pm is 22:00. 0 22 * * * is correct; 0 10 * * * runs at 10am. Read it back as 22 — the higher the PM hour, the easier the AM/PM slip slides past review. 22:00 is the on-ramp to the midnight pile-up. A job here that overruns by two hours lands squarely in the 0 0 * * * rush — backups, logrotate, cert renewals, cache purges all at once — and disk/CPU contention can make everything late. Give it a hard timeout and start it earlier if it routinely runs long.

Cron expression for Every day at 10pm

0 22 * * *

Runs once a day at 10pm, 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 22 * * *`

Running the main nightly batch early enough to retry once before the midnight maintenance window if it fails
Generating tomorrow's scheduled content or campaign so it's queued and reviewed before the team logs off for good
Pulling a daily vendor feed that publishes at the end of the US business day across all timezones

Use `0 22 * * *` 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 22 * * * /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 22 * * *"

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 22 * * *"

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 22 * * *. 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 10pm schedules

10pm is 22:00. 0 22 * * * is correct; 0 10 * * * runs at 10am. Read it back as 22 — the higher the PM hour, the easier the AM/PM slip slides past review.
22:00 is the on-ramp to the midnight pile-up. A job here that overruns by two hours lands squarely in the 0 0 * * * rush — backups, logrotate, cert renewals, cache purges all at once — and disk/CPU contention can make everything late. Give it a hard timeout and start it earlier if it routinely runs long.
"End of US business day" isn't 10pm anywhere consistent. If the box is UTC, 0 22 * * * is 5pm Eastern / 2pm Pacific — Pacific's day isn't over yet, so the feed may be incomplete. Match CRON_TZ to the latest relevant timezone or wait for an explicit "feed ready" signal.

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 22 * * *` the right schedule?

If you want the batch run in the genuinely quiet hours with no daytime overlap, every day at 3am sits clear of both evening jobs and the midnight cluster; choose 10pm only when you need a retry window before midnight.

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