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

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

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

15:00, and there is no 3pm shortcut. Cron wants the 24-hour value, so 0 15 * * * — writing 0 3 * * * gives you 3am. This is the single most common bug on fixed-afternoon jobs; sanity-check by subtracting 12 from PM hours. 3pm collides with everyone else's "end of day" jobs. Reports, exports, and sync tasks cluster in mid-to-late afternoon, so several heavy crons may overlap on the same box. Stagger to an odd minute like 17 15 * * * instead of 0 15 to avoid the top-of-hour thundering herd.

Cron expression for Every day at 3pm

0 15 * * *

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

Running an afternoon inventory or stock reconciliation before warehouse cut-off times for next-day shipping
Refreshing a dashboard with intraday numbers so the team has current figures going into late-afternoon standups
Triggering a daily export to a downstream BI tool that schedules its own ingestion in the 3–4pm window

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

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

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 15 * * *. 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 3pm schedules

15:00, and there is no 3pm shortcut. Cron wants the 24-hour value, so 0 15 * * * — writing 0 3 * * * gives you 3am. This is the single most common bug on fixed-afternoon jobs; sanity-check by subtracting 12 from PM hours.
3pm collides with everyone else's "end of day" jobs. Reports, exports, and sync tasks cluster in mid-to-late afternoon, so several heavy crons may overlap on the same box. Stagger to an odd minute like 17 15 * * * instead of 0 15 to avoid the top-of-hour thundering herd.
If this feeds a same-day cut-off, missed runs hurt. A 3pm job whose box was rebooting at 15:00 just silently skips — cron has no catch-up. Use anacron or a wrapper that checks "did today's run succeed?" when the deadline is real.

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

If the work is genuinely cut-off-driven and must finish before a deadline, a single fixed 3pm run is fragile; every hour with idempotent logic gives you retries through the afternoon instead of one all-or-nothing shot.

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