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

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

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

6pm means 18:00 in cron. 0 18 * * * — not 0 6 * * *, which is 6am. An "evening" job that mysteriously runs at dawn is almost always this twelve-hour slip; verify the hour field reads 18. 6pm sits at the edge of the nightly-batch window and can be the first domino. If this job runs long, it pushes into 7pm/8pm jobs and the start of overnight processing, creating a cascade. Set a timeout (timeout 30m yourjob) so it can't drag the whole evening pipeline late.

Cron expression for Every day at 6pm

0 18 * * *

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

Sending an after-hours reminder or daily digest timed to land as users check personal email in the early evening
Starting an evening backup or batch job once office traffic has tapered but before the heavy late-night window
Running a daily cleanup of expired sessions or carts after the business day closes but before nightly maintenance

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

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

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 18 * * *. 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 6pm schedules

6pm means 18:00 in cron. 0 18 * * * — not 0 6 * * *, which is 6am. An "evening" job that mysteriously runs at dawn is almost always this twelve-hour slip; verify the hour field reads 18.
6pm sits at the edge of the nightly-batch window and can be the first domino. If this job runs long, it pushes into 7pm/8pm jobs and the start of overnight processing, creating a cascade. Set a timeout (timeout 30m yourjob) so it can't drag the whole evening pipeline late.
Evening user-facing emails are timezone-sensitive in a way batch jobs aren't. 0 18 * * * on a UTC box hits a Pacific user at 10–11am, killing the "early evening" effect entirely. For human-timed sends, set CRON_TZ to the recipient's zone or compute send time per-user in app code.

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

If you're really after a recurring evening cleanup rather than one fixed moment, every 6 hours keeps sessions and carts pruned throughout the day instead of letting them pile up until 6pm.

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