What is the cron expression for every wednesday?

The cron expression for every wednesday is "0 0 * * 3". Runs once a week, at midnight every Wednesday.

What should I watch out for when running a cron job every wednesday?

Wednesday is 3, and it's the easiest day to fat-finger as a range bound. Writing 0 0 * * 1-3 when you meant 3 alone turns one weekly run into three (Mon/Tue/Wed). Spell out the single value 3 and read it back before deploying. Midnight Wednesday can collide with a server's weekly maintenance window. Many hosts schedule patch-and-reboot around midweek 00:00 UTC; 0 0 * * 3 launches your job straight into a maintenance reboot and it dies half-run. Check your provider's maintenance schedule and offset to 0 2 * * 3 if it overlaps.

Cron expression for Every Wednesday

0 0 * * 3

Runs once a week, at midnight every Wednesday.

Next 5 runs (your local time)

These are shown in your browser’s timezone. The job itself runs in the scheduler’s timezone — often UTC — so the real run time can differ.

What people actually schedule with `0 0 * * 3`

Running a midweek partial backup or integrity check that splits the week between the Sunday full backup and the weekend window
Posting a recurring "mid-sprint" status report so a two-week sprint gets a checkpoint exactly at its halfway mark
Rotating credentials or API keys on a fixed midweek day so the change lands when the on-call engineer is reliably available

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

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 0 * * 3"

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 0 * * 3. 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 wednesday schedules

Wednesday is 3, and it's the easiest day to fat-finger as a range bound. Writing 0 0 * * 1-3 when you meant 3 alone turns one weekly run into three (Mon/Tue/Wed). Spell out the single value 3 and read it back before deploying.
Midnight Wednesday can collide with a server's weekly maintenance window. Many hosts schedule patch-and-reboot around midweek 00:00 UTC; 0 0 * * 3 launches your job straight into a maintenance reboot and it dies half-run. Check your provider's maintenance schedule and offset to 0 2 * * 3 if it overlaps.
A biweekly "every other Wednesday" cannot be expressed in standard cron. 0 0 * * 3 fires every Wednesday — there's no */2 for day-of-week that respects calendar weeks. For alternating Wednesdays, run weekly and gate inside the script: [ $(( $(date +%V) % 2 )) -eq 0 ] || exit 0 using the ISO week number.

Will you know if this job silently fails?

Cron jobs fail quietly — a server reboots, a path changes, or an error code is ignored — and nobody notices until the data is missing. A cron monitor (a dead-man’s-switch) alerts you when a scheduled job does not check in on time.

Monitor your cron jobs with UptimeRobot →

Disclosure: this is an affiliate link — we may earn a commission if you sign up, at no extra cost to you.

Is `0 0 * * 3` the right schedule?

If you actually want a fortnightly cadence rather than weekly, twice a month gives a cleaner expressible rhythm than faking alternating Wednesdays in shell. Stay on 0 0 * * 3 only when every single week needs the run.

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