Every Day at 6 PM Cron Expression
Runs once daily at 18:00 — end-of-workday slot.
0 18 * * * in POSIX cron
Expression
0 18 * * *Try it in the tester →Field Breakdown
How It Works
Fires at 18:00 every day — useful for end-of-day rollups, summary emails, and after-hours cleanup.
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 hour 18 instead of 6?
Cron uses 24-hour time. Hour 18 is 6 PM, hour 6 is 6 AM.
0 18 * * * in Quartz / Spring
Daily at 18:00 — the close-of-business hour expressed in the 24-hour clock Quartz requires. Crontab veterans parse this instantly; the only Quartz-specific furniture is the leading seconds zero and the trailing ?.
Quartz / Spring expression
0 0 18 * * ?Try it in the tester →At 18:00:00
Unix / POSIX equivalent: 0 18 * * *
Field Breakdown
Using It with Quartz / Spring
Evening triggers collect the day: rolling up the day's orders, snapshotting metrics before overnight processing rewrites them, sweeping temp files created during business hours. Spring services take it as @Scheduled(cron = "0 0 18 * * ?"), Quartz proper via cronSchedule() on a trigger builder. Be deliberate about what "the day" means to this job — a run starting at 18:00 sees only about three quarters of a calendar day's activity, so end-of-day reports built here will diverge from ones computed after midnight, and that difference should be a documented choice rather than a surprise.
Quartz-Specific Notes
- →18 in the hour slot is the only way to say 6 PM; writing 6 would give you 06:00, and the grammar has no meridiem markers to catch the mistake.
- →The schedule includes Saturdays and Sundays — 365 firings a year (366 in leap years) — which is fine for cleanup but noisy for human-facing summaries.
- →An evening run that overlaps a nightly batch window can contend for the same tables; check what else your platform schedules between 18:00 and midnight before adding heavy work here.
Frequently Asked Questions
Does this respect daylight saving time?
It fires at 18:00 wall-clock in the trigger's timezone, so yes — on the absolute timeline the fire moments shift by an hour twice a year, which is exactly what a local-evening job wants. Use a fixed-offset zone like UTC if you need uniform spacing instead.
How do I make this weekdays-only without breaking the expression?
Two coordinated edits: put 2-6 in day-of-week and change day-of-month from * to ? — giving 0 0 18 ? * 2-6. Leaving * in both day fields is a parse error in Quartz.
Is 0 0 18 * * ? the same as Spring's fixedRate every 24 hours?
No. fixedRate counts milliseconds from application start, so the firing time drifts with every restart. The cron form is anchored to the calendar and always means 18:00 regardless of when the app booted.
0 18 * * * in AWS EventBridge
365 invocations a year, one each evening at 18:00 UTC. It reads as an end-of-day trigger, though what "end of day" means depends on the meridian: 18:00 UTC is mid-afternoon in New York, dinnertime in Berlin, and 03:00 the next morning in Tokyo.
AWS EventBridge expression
cron(0 18 * * ? *)Try it in the tester →At 18:00 UTC
Unix / POSIX equivalent: 0 18 * * *
Field Breakdown
Using It with AWS EventBridge
In CDK, construct an events.Rule with Schedule.expression("cron(0 18 * * ? *)") and add the evening workload as a target. Typical tenants of this hour are exports that ship the day's transactions to a partner SFTP via a Fargate task, rollup jobs that close out daily counters into a reporting table, and cleanup functions that tear down ephemeral preview environments spun up during the workday. Teams running a strict UTC data day sometimes prefer 18:00 over midnight precisely so the export lands while engineers are still awake to fix a failure.
AWS-Specific Notes
- →If the day's data keeps arriving until 23:59 UTC, an 18:00 export captures only three-quarters of it — confirm whether the business wants "end of business" or "end of calendar day" before choosing this over a midnight run.
- →An evening counterpart to a morning rule can live in this same expression by listing both hours, cron(0 6,18 * * ? *), though both fires then deliver an identical event payload.
- →Delivery is at-least-once: an idempotency check keyed on the event's scheduled timestamp prevents a rare duplicate from double-shipping the same export.
Frequently Asked Questions
How can the target tell this was the 6 PM run if I add more hours later?
Parse the time field in the scheduled-event JSON; it carries the matched UTC timestamp, so 18:00:00Z identifies the evening slot even if the rule later also fires at other hours.
Is 18:00 UTC a sensible end-of-day for a US-based company?
It equals 13:00–14:00 US Eastern, so probably not. Either schedule at 22:00 or 23:00 UTC to approximate East Coast close of business, or use EventBridge Scheduler with America/New_York so the run pins to 18:00 local across DST.
0 18 * * * in GitHub Actions
A single daily run at 18:00 UTC, every day of the week. For UTC-adjacent teams this is close-of-business; for New York it is 1:00 or 2:00 PM, and for Berlin it is 7:00 or 8:00 PM — "6 PM" only describes one slice of the planet.
GitHub Actions expression
0 18 * * *Try it in the tester →At 18:00 UTC
Unix / POSIX equivalent: 0 18 * * *
Field Breakdown
Using It with GitHub Actions
Committed as on: schedule: - cron: "0 18 * * *" in a default-branch workflow, the 18:00 UTC slot handles wind-down automation for UK and Western European projects: archiving the day's CI artifacts, tearing down ephemeral review environments nobody will touch overnight, or posting a what-merged-today summary. American teams sometimes adopt the same line for a different reason — it lands early afternoon Eastern, a reasonable point to refresh data midway through the US workday. Because the day fields are wildcards, the job also fires on weekends, when an end-of-day summary may have nothing to say; an early-exit check on activity keeps those runs cheap.
GitHub-Specific Notes
- →18:00 UTC translates to 13:00 or 14:00 in New York and 19:00 or 20:00 in Berlin depending on the season — pin down which audience this run serves before assuming it means evening.
- →Editing the cron line in a feature branch changes nothing until the merge lands; the scheduler reads only the default branch's copy of the file.
- →Seven runs a week, including Saturday and Sunday — append 1-5 to the day-of-week field if weekend output is noise.
Frequently Asked Questions
Does 0 18 * * * also run at 6 in the morning?
No — the hour field uses the 24-hour clock, so 18 is strictly 6 PM UTC. A morning companion run needs its own entry, 0 6 * * *, in the schedule list.
I want this at 6 PM New York time. What do I write?
0 22 * * * while daylight saving is active (EDT is UTC-4) and 0 23 * * * in winter (EST is UTC-5). GitHub will not switch between them for you, so pick one or update the file twice a year.