Cron expression for Every day at 8pm

What people actually schedule with 0 20 * * *

• Sending a prime-time evening notification or content drop to hit the 8–9pm mobile usage peak
• Running a nightly report build that needs to be ready first thing the next morning without waiting until 3am
• Triggering a daily sync to a third-party system that processes inbound files during its overnight batch window

Use 0 20 * * * 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 20 * * * /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 20 * * *"

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

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 20 * * *. 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 8pm schedules

• 8pm is 20:00, not 8. 0 20 * * * is right; 0 8 * * * fires at 8am. The mental check: 8pm = 8 + 12 = 20. A prime-time notification that goes out at breakfast is this exact mistake.
• Prime-time sends amplify timezone errors across a global list. One 0 20 * * * on a UTC server hits New York at 3pm and Tokyo at 5am simultaneously — there is no single "8pm" for a worldwide audience. Bucket users by timezone and schedule per-zone, or stagger sends in app logic rather than one cron line.
• 8pm feeds the overnight chain, so its failures are invisible till morning. If the 8pm report build dies, no alert fires until someone opens an empty dashboard at 9am. Pipe failures to a pager (|| curl -fsS your-alert-url) instead of relying on cron mail nobody reads at night.

Is 0 20 * * * the right schedule?

If "ready by morning" is the only real requirement, every day at 6am builds the report on the freshest possible data right before business hours; pick 8pm only if downstream systems need the output during their own night batch.

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

• Every day at 9pm 0 21 * * *
• Every day at 10pm 0 22 * * *
• Every day at 11pm 0 23 * * *
• Every weekday 0 0 * * 1-5
• Every weekday at 5pm 0 17 * * 1-5
• Every weekday at 6pm 0 18 * * 1-5