Weekdays at 6 PM Cron Expression
Runs Monday through Friday at 18:00.
0 18 * * 1-5 in POSIX cron
Expression
0 18 * * 1-5Try it in the tester →Field Breakdown
How It Works
Hour pinned to 18, day-of-week restricted to Mon–Fri. Common for end-of-business-day rollups.
Example Run Times
- Mon 18:00:00
- Tue 18:00:00
- Wed 18:00:00
- Thu 18:00:00
- Fri 18:00:00
Frequently Asked Questions
Why 18 instead of 6?
Cron uses 24-hour time. Hour 18 = 6 PM. Hour 6 would mean 6 AM.
0 18 * * 1-5 in Quartz / Spring
Five firings a week, each at 18:00 Monday through Friday — about 260 a year. Both constraints that define it live at the ends of the expression: hour 18 in the third field, weekday range 2-6 in the last.
Quartz / Spring expression
0 0 18 ? * 2-6Try it in the tester →At 18:00:00 on Mon, Tue, Wed, Thu, Fri
Unix / POSIX equivalent: 0 18 * * 1-5
@Scheduled parser uses 0–7 with Monday = 1 — numeric day values mean different days in the two. The day names (MON, FRI, MON-FRI) are identical in both and safer to copy between them.Field Breakdown
Using It with Quartz / Spring
Close-of-business on working days is the natural home for timesheet reminder nudges, daily sales tallies, and handoff summaries for a follow-the-sun support rotation. Since 6 PM only means something in the office's timezone, this is a schedule worth pinning explicitly: @Scheduled(cron = "0 0 18 ? * 2-6", zone = "Europe/Berlin") in Spring, or inTimeZone() on the Quartz schedule builder. Anchored that way, the trigger keeps tracking local evening through every DST transition without anyone editing the hour field.
Quartz-Specific Notes
- →The 2-6 range is Monday-Friday only because Quartz starts its week at Sunday=1; the same digits mean Tuesday-Saturday in a Unix crontab, where Monday is 1.
- →MON-FRI is valid in place of 2-6 and produces byte-for-byte identical fire times.
- →There is no firing between Friday 18:00 and Monday 18:00 — anything queued by users over the weekend waits for Monday evening, which may argue for a separate weekend trigger if that latency matters.
Frequently Asked Questions
Why does my supposedly weekday job run on Sunday (and skip Friday) after migrating to Quartz?
Most likely the day range was carried over as 1-5 from Unix cron, where that means Monday-Friday. Under Quartz's Sunday-first numbering 1-5 is Sunday-Thursday — wrong on both ends. The correct Quartz range is 2-6.
Can this skip company holidays automatically?
Not through the expression — cron syntax has no holiday concept. Quartz offers HolidayCalendar: register the excluded dates with the scheduler and attach the calendar to this trigger with modifiedByCalendar(), and those firings are suppressed.
How do I shift this to 17:45 so reports are ready by 6?
Adjust minute and hour together: 0 45 17 ? * 2-6. Everything about the weekday filter stays as is.
0 18 * * 1-5 in AWS EventBridge
Five fires a week — 18:00 UTC on days 2 through 6, EventBridge's encoding of Monday through Friday — for roughly 261 invocations a year. This is the canonical evening leg of workday automation: whatever a morning rule switched on, this one switches off.
AWS EventBridge expression
cron(0 18 ? * 2-6 *)Try it in the tester →At 18:00 UTC on Mon, Tue, Wed, Thu, Fri
Unix / POSIX equivalent: 0 18 * * 1-5
Field Breakdown
Using It with AWS EventBridge
The most common payload is cost hygiene: a Lambda behind this rule calls StopInstances on tagged dev and test EC2 boxes, stops non-production RDS clusters, or scales ECS services to zero for the night, clawing back the 60-plus percent of compute hours that sit between evenings and mornings. The same shape also drives end-of-business exports — order files cut at close of day, time-tracking summaries, branch-protection sweeps — anything that should happen after staff stop making changes but before overnight batches begin.
AWS-Specific Notes
- →18:00 UTC is 13:00–14:00 US Eastern, so as a "close of business" trigger for American offices it is several hours premature; an EventBridge Scheduler schedule with America/New_York fixes the intent without changing the cron body.
- →Stopping resources is destructive enough to deserve a guard: scope the IAM role to a tag like AutoStop=true so a misconfigured rule cannot touch production.
- →The weekday range uses Sunday-first numbers — 2-6 is MON-FRI — and forces the ? into day-of-month.
Frequently Asked Questions
Can I leave Friday running and only stop instances Monday through Thursday?
Shrink the range by one: cron(0 18 ? * 2-5 *) covers Monday(2) through Thursday(5). Pair it with a separate weekend-aware policy for Friday if instances should survive into Saturday.
What stops a stopped instance from being started again at 6 PM?
Nothing in EventBridge itself — StopInstances on an already-stopped instance is simply a no-op. The asymmetric risk is the reverse rule starting things you stopped manually, which is why start and stop logic should check tags rather than act on every instance.
Is one rule for all five days better than five single-day rules?
Almost always yes: one expression, one target, one set of metrics. Split into per-day rules only when different days genuinely need different payloads or different fire times.
0 18 * * 1-5 in GitHub Actions
Hour 18, Monday through Friday: five runs a week at 18:00 UTC, about 260 a year. This is close-of-business automation for the UTC band — London gets it at 6 PM in winter and 7 PM in summer — while New York receives the same tick in the early afternoon.
GitHub Actions expression
0 18 * * 1-5Try it in the tester →At 18:00 UTC on Mon, Tue, Wed, Thu, Fri
Unix / POSIX equivalent: 0 18 * * 1-5
Field Breakdown
Using It with GitHub Actions
Declared as on: schedule: - cron: "0 18 * * 1-5" in a default-branch workflow, the weekday-evening pattern drives daily wrap-up work that would be pointless on weekends: tallying the day's merged pull requests into a digest, shutting down review apps spun up during the day, or promoting the day's last green build to an internal QA channel. The 1-5 day-of-week range (Sunday counts as 0) does the weekday filtering in the schedule itself, so the job never even starts on Saturday or Sunday rather than starting and exiting.
GitHub-Specific Notes
- →The week's rhythm is uneven by design: 24 hours between weekday ticks, then a 72-hour silence from Friday 18:00 to Monday 18:00 — Monday's run covers three days of accumulated changes.
- →18:00 UTC is 13:00 or 14:00 in New York, so for a US team this is a mid-afternoon checkpoint, not an end-of-day ritual; shift the hour to 22 or 23 to match Eastern close-of-business.
- →The 1-5 range relies on Sunday being 0; the identical schedule written with names, 0 18 * * MON-FRI, removes any ambiguity for future readers.
Frequently Asked Questions
Why does my end-of-day job run at lunchtime for the New York office?
Because 18:00 is a UTC hour and New York sits four or five hours behind. For a 6 PM Eastern run use 0 22 * * 1-5 during daylight saving or 0 23 * * 1-5 in winter — though note the EST version technically fires at 23:00 UTC, still the same weekday.
Will this skip national holidays that fall on a weekday?
No — cron knows weekdays, not holidays. If holiday silence matters, add a leading step that checks the date against a holiday list or API and exits early.