Cron expression for Every day at 11am

What people actually schedule with 0 11 * * *

• Late-morning publishing or send timed to catch readers just before they break for lunch
• Pre-lunch reconciliation jobs that fold in the morning's transactions before midday reporting
• Refreshing dashboards and KPIs so management has current numbers for end-of-morning reviews

Use 0 11 * * * 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 11 * * * /path/to/your-command

Runs in the server’s local timezone — check it with timedatectl. Full field reference: crontab(5) man page.

GitHub Actions

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

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 11 * * *"

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 11 * * *. 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 day at 11am schedules

• 11am sends race the lunch dead zone. Fire a campaign at 11 and a chunk of recipients are already heading out — opens stall until afternoon, distorting same-day metrics if you judge performance too early. If timing matters, A/B 11am against an early-afternoon slot rather than assuming late-morning is optimal.
• It runs squarely in business hours, so it competes with live load and locks. An 11am reconciliation that takes table locks can stall checkout or reporting queries mid-day. Run it in a read replica or a short transaction, and wrap with flock -n so a slow day's run never overlaps the next trigger or a manual re-run.
• Time-zone drift makes "11am" meaningless across regions. 0 11 * * * on a UTC box is 3am in California and 8pm in Tokyo — your pre-lunch intent only holds for one zone. Set CRON_TZ= explicitly to the audience's locale, and for multi-region sends schedule per-zone instances instead of one global 11am fire.

Is 0 11 * * * the right schedule?

If you want guaranteed attention before the midday drop-off, 9am catches people while they're still at their desks fresh. For data jobs that only need to be ready by an afternoon review, run the heavy lifting overnight at 3am and refresh lightly at 11.

Or use the interactive cron generator & explainer, read the complete cron syntax guide, or pick another common schedule:

• Every day at 1pm 0 13 * * *
• Every day at 2pm 0 14 * * *
• Every day at 3pm 0 15 * * *
• Every day at 4pm 0 16 * * *
• Every day at 5pm 0 17 * * *
• Every day at 6pm 0 18 * * *