Daily at 6 PM Cron Expression

Linux cron

0 18 * * *

Quartz cron

0 0 18 * * *

What this schedule does

0 18 * * * runs every day at 18:00. In standard Linux cron, the five fields are minute, hour, day of month, month, and day of week. The equivalent Quartz-style expression is 0 0 18 * * *, which usually adds a seconds field at the beginning.

Treat the expression as a trigger, not as a complete job policy. Timezone, retries, locking, alerting, and missed-run behavior are controlled by the scheduler or by your application code.

Field breakdown

Field	Value	Meaning	Practical note
Minute	`0`	Minute field is 0.	Specific minute: 0.
Hour	`18`	Hour field is 18.	Specific hour: 18.
Day of month	`*`	Day-of-month field is *.	Every valid day of month.
Month	`*`	Month field is *.	Every valid month.
Day of week	`*`	Day-of-week field is *.	Every valid day of week.

Field reference

Read 0 18 * * * from left to right as minute, hour, day of month, month, and day of week. A value of * means every valid value, */n means every n units, commas select multiple values, and ranges select a continuous span.

Field	Allowed values	Common syntax	Implementation note
Minute	0-59	*, comma lists, ranges, and steps	Use small intervals only for lightweight or locked jobs.
Hour	0-23	24-hour UTC or scheduler-local values	Check whether the platform evaluates in UTC before copying the schedule.
Day of month	1-31	Exact days, ranges, steps, or *	Month length can skip impossible dates such as the 31st in shorter months.
Month	1-12 or JAN-DEC	Numeric or named months where supported	Named months are convenient but not accepted by every parser.
Day of week	0-7 or SUN-SAT	0 and 7 usually both mean Sunday	Some schedulers combine day-of-month and day-of-week differently.

Next 10 UTC run times

#	UTC time	ISO 8601	Relative
1	Fri, 31 Jul 2026 18:00:00 GMT	`2026-07-31T18:00:00.000Z`	in 8 hr 3 min
2	Sat, 01 Aug 2026 18:00:00 GMT	`2026-08-01T18:00:00.000Z`	in 32 hr 3 min
3	Sun, 02 Aug 2026 18:00:00 GMT	`2026-08-02T18:00:00.000Z`	in 2 days 8 hr
4	Mon, 03 Aug 2026 18:00:00 GMT	`2026-08-03T18:00:00.000Z`	in 3 days 8 hr
5	Tue, 04 Aug 2026 18:00:00 GMT	`2026-08-04T18:00:00.000Z`	in 4 days 8 hr
6	Wed, 05 Aug 2026 18:00:00 GMT	`2026-08-05T18:00:00.000Z`	in 5 days 8 hr
7	Thu, 06 Aug 2026 18:00:00 GMT	`2026-08-06T18:00:00.000Z`	in 6 days 8 hr
8	Fri, 07 Aug 2026 18:00:00 GMT	`2026-08-07T18:00:00.000Z`	in 7 days 8 hr
9	Sat, 08 Aug 2026 18:00:00 GMT	`2026-08-08T18:00:00.000Z`	in 8 days 8 hr
10	Sun, 09 Aug 2026 18:00:00 GMT	`2026-08-09T18:00:00.000Z`	in 9 days 8 hr

Linux crontab

0 18 * * * /usr/local/bin/job.sh

GitHub Actions

on:
  schedule:
    - cron: "0 18 * * *"

Kubernetes CronJob

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "0 18 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure

Jenkins Pipeline

pipeline {
  triggers { cron('0 18 * * *') }
}

AWS EventBridge note

EventBridge schedule expression:
cron(0 18 * * ? *)

Node.js node-cron

import cron from "node-cron";

cron.schedule("0 18 * * *", async () => {
  await runJob();
}, { timezone: "UTC" });

Python APScheduler

from apscheduler.triggers.cron import CronTrigger
from apscheduler.schedulers.background import BackgroundScheduler

scheduler = BackgroundScheduler(timezone="UTC")
scheduler.add_job(run_job, CronTrigger.from_crontab("0 18 * * *"))
scheduler.start()

Go robfig/cron

import "github.com/robfig/cron/v3"

c := cron.New(cron.WithLocation(time.UTC))
c.AddFunc("0 18 * * *", runJob)
c.Start()

Spring scheduled job

@Scheduled(cron = "0 0 18 * * *", zone = "UTC")
public void runJob() {
    // keep this method idempotent
}

Good use cases

Run repeatable maintenance, reporting, automation, or background processing tasks.
Use the schedule for jobs that can tolerate cron-style timing instead of real-time events.
Keep the job idempotent so manual retries and delayed starts remain safe.

Production checklist

Check	Why it matters
Timezone	Confirm whether the scheduler uses UTC, server local time, or an explicit timezone setting.
Overlap	Make the job idempotent or add a lock if one run can last longer than the interval.
Retries	Cron starts jobs; it does not define retry, backoff, alerting, or dead-letter behavior.
Platform syntax	This is standard five-field cron syntax for Linux-style schedulers.
Monitoring	Log the scheduled time, actual start time, duration, exit code, and next expected run.

Runtime decisions

Before this schedule goes live, decide what should happen when a previous run is still active, when the server restarts during a scheduled minute, and when the job fails after partially changing data. Those rules are usually more important than the cron string itself.

Decision	Recommended default	Reason
Timezone	Use UTC unless the job is tied to a local business day.	UTC avoids daylight-saving surprises and makes logs easier to compare.
Concurrency	Allow only one active run for state-changing jobs.	Overlapping runs can duplicate emails, invoices, imports, or cleanup work.
Missed starts	Record the intended scheduled time and decide whether to catch up.	Some platforms skip missed runs while others start late after downtime.
Retries	Use application-level retries with bounded backoff.	Cron only triggers the job; it does not know whether the work completed correctly.

Platform differences

Platform	Typical format	Important behavior
Linux crontab	`0 18 * * *`	Five fields. Usually runs in the server timezone unless the environment or cron implementation sets another timezone.
GitHub Actions	`0 18 * * *`	Uses five-field cron and evaluates schedules in UTC. Jobs may be delayed during high load.
Kubernetes CronJob	`0 18 * * *`	Controller behavior controls missed starts, concurrency policy, history limits, and timezone support.
Quartz / Spring	`0 0 18 * * *`	Often uses seconds and supports `?`, `L`, and other non-Linux cron features.

Usage notes

Daily at 6 PM is useful for scheduled maintenance, reporting, automation, and background jobs. Confirm the scheduler time zone and platform syntax before deploying it to production.

Platform difference: standard Linux cron uses five fields. Quartz and AWS style schedules often add seconds or year fields and use ? for “no specific value”. GitHub Actions evaluates cron in UTC. Kubernetes follows standard cron syntax through the controller timezone unless configured otherwise.

Common mistake: copying a Quartz expression into Linux crontab without removing the seconds field. Another common issue is assuming local time when the platform evaluates schedules in UTC.

Daily at 6 PM