Cron expression for Every weekday at 5pm
0 17 * * 1-5
Runs at 5pm 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 17 * * 1-5
- Firing an end-of-day close: snapshotting the day's sales or ticket totals at the moment the office shuts, so the daily report reflects a full business day
- Triggering a 5pm "go home" automation — clocking out idle CI runners, scaling down dev environments, or posting a wrap-up summary as the workday ends
- Kicking off an overnight ETL that should start the instant business hours close so data is fresh by morning but no live users are hitting the source DB
Use 0 17 * * 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 17 * * 1-5 /path/to/your-commandRuns in the server’s local timezone — check it with timedatectl.
Full field reference: crontab(5) man page.
GitHub Actions
on:
schedule:
- cron: "0 17 * * 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 17 * * 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 17 * * 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 5pm schedules
- 17:00 server time is almost never your team's 5pm. On a UTC host,
0 17 * * 1-5is 9am Pacific / noon Eastern — the start of the day, not the end. "End of business" jobs are the single most common cron timezone bug; setTZ=America/New_York(or your office zone) explicitly so DST shifts come along for free. - Friday 5pm is the worst possible time for a job that can fail silently. Whatever breaks here sits broken all weekend because nobody's watching until Monday. If this run is load-bearing, route failures to an on-call alert, not just cron mail —
command || curl -fsS https://your-healthcheck/fail. - 5pm is rush hour for schedulers too. Top-of-hour on a round number like 17:00 is where everyone piles their cron jobs, so on shared or managed runners you may queue behind a stampede and fire late. Offset by a few minutes (
3 17 * * 1-5) to dodge the :00 crowd.
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 17 * * 1-5 the right schedule?
If a 5pm close is too early because your team works late, push it to every weekday at 6pm. If you don't need the weekend skip at all, every day at 5pm keeps weekends covered with the same clock time.
Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule: