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

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

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

13:00 is unambiguous, but your config might not be. Cron only understands 24-hour fields, so 0 13 * * * is correct and there is no AM/PM token — if you copied 0 1 * * * thinking "1pm," you just scheduled 1am. Read it back as 24-hour every time. This fires during peak business load. A 1pm job competes with live user traffic for CPU and DB connections, unlike a quiet 3am window. Cap concurrency and add nice -n 19 / ionice so a heavy run doesn't degrade the app for real users mid-afternoon.

Cron expression for Every day at 1pm

0 13 * * *

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

Sending a midday digest or summary email right after the lunch lull, when open rates climb back up
Triggering an early-afternoon data sync from a partner system that finalizes its morning batch around noon
Posting a scheduled social update at 1pm to catch the post-lunch desktop browsing window

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

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

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 13 * * *. 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 1pm schedules

13:00 is unambiguous, but your config might not be. Cron only understands 24-hour fields, so 0 13 * * * is correct and there is no AM/PM token — if you copied 0 1 * * * thinking "1pm," you just scheduled 1am. Read it back as 24-hour every time.
This fires during peak business load. A 1pm job competes with live user traffic for CPU and DB connections, unlike a quiet 3am window. Cap concurrency and add nice -n 19 / ionice so a heavy run doesn't degrade the app for real users mid-afternoon.
Server timezone, not yours, decides when 1pm happens. If the box runs UTC and your audience is Pacific, 0 13 * * * fires at 5–6am local — not the post-lunch slot you wanted. Set CRON_TZ=America/Los_Angeles or convert the hour explicitly.

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

If the exact minute doesn't matter and you just want "sometime in the afternoon," leave it here; but if this is a recurring API poll rather than a once-a-day event, every hour spreads the load instead of slamming it all at 1pm.

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