0 12 * * ? *
0 12 * * ? *
What this schedule does
0 12 * * ? * runs aws eventbridge style daily schedule. 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 12 * * ? *, 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 | 12 | Hour field is 12. | Specific hour: 12. |
| 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 ?. | No specific day of week; common in Quartz-style schedules. |
Field reference
Read 0 12 * * ? * 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
This expression uses platform-specific syntax such as Jenkins H, Quartz ?, AWS year fields, or last-day markers. Use the platform scheduler preview for exact future run times.
Linux crontab
0 12 * * ? * /usr/local/bin/job.shGitHub Actions
on:
schedule:
- cron: "0 12 * * ? *"Kubernetes CronJob
apiVersion: batch/v1
kind: CronJob
spec:
schedule: "0 12 * * ? *"
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailureJenkins Pipeline
pipeline {
triggers { cron('0 12 * * ? *') }
}AWS EventBridge note
EventBridge schedule expression:
Convert this schedule in the AWS EventBridge console because it uses platform-specific cron syntax.Node.js node-cron
import cron from "node-cron";
cron.schedule("0 12 * * ? *", 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 12 * * ? *"))
scheduler.start()Go robfig/cron
import "github.com/robfig/cron/v3"
c := cron.New(cron.WithLocation(time.UTC))
c.AddFunc("0 12 * * ? *", runJob)
c.Start()Spring scheduled job
@Scheduled(cron = "0 12 * * ? *", 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 schedule includes platform-specific syntax. Verify it in Jenkins, Quartz, AWS, or the target scheduler. |
| 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 12 * * ? * | Five fields. Usually runs in the server timezone unless the environment or cron implementation sets another timezone. |
| GitHub Actions | 0 12 * * ? * | Uses five-field cron and evaluates schedules in UTC. Jobs may be delayed during high load. |
| Kubernetes CronJob | 0 12 * * ? * | Controller behavior controls missed starts, concurrency policy, history limits, and timezone support. |
| Quartz / Spring | 0 12 * * ? * | Often uses seconds and supports ?, L, and other non-Linux cron features. |
Usage notes
AWS EventBridge Daily 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.