Cron expression for Every weekday at 6pm
0 18 * * 1-5
Runs at 6pm Monday through Friday; skips weekends.
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 * * 1-5
- Running an after-hours backup or maintenance window that waits until the office has genuinely cleared out — 6pm catches the late stayers that a 5pm job would interrupt
- Posting a true end-of-day rollup once stragglers have logged their last tickets, so the 6pm number is final rather than a 5pm snapshot that still moves
- Starting a heavy reindex or batch job an hour into the evening, deliberately offset from the 5pm crowd so it doesn't contend with everyone else's close-of-business tasks
Use 0 18 * * 1-5 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 * * 1-5 /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 * * 1-5"
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 * * 1-5"
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 * * 1-5. 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 weekday at 6pm schedules
- 18:00 in the wrong timezone defeats the entire "after hours" point. On a UTC server
0 18 * * 1-5lands at 10am Pacific / 1pm Eastern — smack in the middle of the workday you were trying to avoid. PinTZ=to the office zone, because the whole value of 6pm is being after people, not before. - An 18:00 job that overruns can collide with the nightly backup window. Push a long ETL to 6pm and it may still be holding table locks or hammering I/O when logrotate, snapshots, or the 11pm backup kicks off. Time-box it (
timeout 2h command) or stagger so the evening pipeline doesn't pile up. - Friday 18:00 buys you the latest safe start before the weekend blind spot. But anything that fails here still goes unnoticed until Monday, and an hour later than 5pm means even less daylight for a human to catch it. Wrap it with an external dead-man's-switch ping so a missed Friday run alerts you, not silence.
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 * * 1-5 the right schedule?
If 6pm is later than you need and you'd rather have more eyes on failures, pull it back to every weekday at 5pm. If weekends shouldn't be skipped, every day at 6pm runs the same 18:00 slot seven days a week.
Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: