How to Calculate Cron Schedule for Every 4 Hours Excluding Weekends

Quick Win: The Cron Expression You Actually Need

Here's the expression that runs every 4 hours, Monday through Friday, no weekend noise:

0 */4 * * 1-5

That's it. Six executions per day (midnight, 4 AM, 8 AM, noon, 4 PM, 8 PM), five days a week. Thirty total runs. Zero Saturday or Sunday triggers. If you're managing batch jobs for a business-hours analytics pipeline or a weekday-only data sync, this is your baseline. Now let's walk through how to build, validate, and deploy this schedule without second-guessing yourself at 3 AM on a Saturday.

Step 1: Decode the Five-Field Cron Structure

Before you tweak a single asterisk, know what you're looking at. Standard cron expressions use five fields, separated by spaces:

• Minute — 0 to 59
• Hour — 0 to 23
• Day of Month — 1 to 31
• Month — 1 to 12 (or JAN through DEC)
• Day of Week — 0 to 7 (where 0 and 7 are both Sunday; or SUN through SAT)

Some systems support a sixth field for seconds at the front, but for most scheduling tools — Linux crontab, GitHub Actions, AWS EventBridge — the five-field format is the standard. If you're working in a platform that uses Quartz (like Spring Boot), field order and day-of-week numbering can differ slightly. More on that in Step 5.

Step 2: Lock In the "Every 4 Hours" Interval

The hour field is where the interval lives. The syntax */4 means "every 4 hours starting at hour 0." That gives you triggers at 00:00, 04:00, 08:00, 12:00, 16:00, and 20:00.

Set the minute field to 0 so each run fires on the top of the hour. Clean. Predictable. Easy to grep in logs later.

Your expression so far: 0 */4 * * *

This runs every 4 hours, every day, including weekends. Not what you want yet. But it's the foundation.

What If You Want a Different Start Time?

Say your first run should fire at 2 AM instead of midnight. You'd list explicit hours: 0 2,6,10,14,18,22 * * *. Same 4-hour gap, different anchor. This matters when you're coordinating with a downstream system that needs a 2-hour head start on processing before your job kicks in.

Step 3: Exclude Weekends With the Day-of-Week Field

The fifth field controls which days of the week the job runs. To exclude Saturday and Sunday, use a range that covers Monday through Friday only.

In standard cron: 1-5 (where 1 = Monday, 5 = Friday).

Your expression now: 0 */4 * * 1-5

This is the final form. Let's verify what it actually does:

• Monday 00:00 — runs
• Monday 04:00 — runs
• ...continues every 4 hours through Friday 20:00
• Friday 23:59 through Sunday 23:59 — silent
• Monday 00:00 — resumes

Thirty executions per week. No weekend runs. No manual pausing required.

Step 4: Validate Before You Deploy

Never push a cron expression to production without confirming the next fire times. One misplaced character and you're either running every 4 minutes (embarrassing) or not at all (worse).

Here's how to validate across common environments:

Linux crontab

Use a parser tool like croniter (Python) or an online cron expression tester. Feed it 0 */4 * * 1-5 and check the next 10 fire dates. You should see only weekday timestamps, 4 hours apart.

GitHub Actions

GitHub Actions uses POSIX cron syntax. The expression 0 */4 * * 1-5 works directly in your workflow file:

on: schedule: - cron: "0 */4 * * 1-5"

Note: GitHub Actions schedules run in UTC. If your team operates in US Eastern time, a midnight UTC trigger fires at 7 PM or 8 PM local time depending on daylight saving. Always convert.

AWS EventBridge

EventBridge supports the same five-field syntax. Create a rule with the schedule expression cron(0 */4 * * ? 1-5). Note the ? in the day-of-month field — AWS requires either a day-of-month or a day-of-week, and uses ? to indicate "don't care" for the other. If you use * for both, AWS rejects it.

Step 5: Watch Out for Platform-Specific Quirks

Cron syntax looks universal. It isn't. Here are the traps that catch people:

Quartz-Based Systems (Spring Boot, Java schedulers)

Quartz uses a six or seven field format and numbers Sunday as 1, not 0 or 7. To exclude weekends in Quartz, use 2-6 for Monday through Friday. The full expression: 0 0 0/4 * * 2-6. If you copy-paste 1-5 from a Linux crontab into a Quartz config, you'll exclude Sunday and Monday instead of Saturday and Sunday. That's a Monday morning surprise nobody wants.

Daylight Saving Time

Cron doesn't understand DST. When clocks spring forward, the 2 AM trigger may be skipped entirely. When they fall back, a 1 AM or 2 AM job might fire twice. For a 4-hour interval, this means one cycle per year gets a 5-hour gap and another gets a 3-hour gap. If your job is idempotent and handles re-runs gracefully, this is fine. If not, add a lock mechanism or idempotency check.

Timezone Assumptions

Most Linux cron daemons run in the server's local timezone. Cloud services often default to UTC. If your "weekday" boundary matters — say, you need jobs to stop at Friday midnight local time — make sure the timezone is explicitly set. In Kubernetes CronJobs, you can specify timeZone: "America/New_York" in the spec (available in Kubernetes 1.25+).

Step 6: Document the Schedule for Your Team

A cron expression without context is a mystery waiting to happen. When someone joins the team and sees 0 */4 * * 1-5 in a config file, they should immediately understand:

• What it runs (which script or job)
• Why it runs on this cadence (business logic)
• Why weekends are excluded (cost savings? business relevance? downstream dependency availability?)
• What timezone it executes in
• Who to contact when it fails

Add a comment block above the cron entry or a note in your scheduling documentation. Future you will thank present you.

Step 7: Monitor and Handle Failures Gracefully

A schedule is only as good as its observability. Every 4-hour job that silently fails for an entire weekend is a Monday disaster. Here's the minimum viable monitoring setup:

• Alerting: Send a notification (Slack, PagerDuty, email) on non-zero exit codes. Don't rely on log review.
• Dead letter handling: If the job produces output files or writes to a queue, monitor for gaps. A missing 4 PM file on Thursday should trigger an alert before Friday.
• Retry logic: For transient failures (network blips, temporary DB locks), implement a retry with exponential backoff. One retry after 60 seconds covers most flaky dependencies.
• Last-run timestamp: Write a heartbeat to a monitoring table or file after each successful run. If the heartbeat is older than 5 hours on a weekday, something's wrong.

The Full Workflow, Summarized

Here's the end-to-end checklist for deploying a weekday-only, every-4-hours cron job:

1. Start with 0 */4 * * * for the base 4-hour interval
2. Add 1-5 in the day-of-week field to exclude weekends → 0 */4 * * 1-5
3. Verify the platform's cron dialect (POSIX vs Quartz vs AWS)
4. Convert to the correct timezone if your platform uses UTC
5. Validate the next 10 fire times using a cron parser
6. Deploy with monitoring, alerting, and retry logic
7. Document the schedule, purpose, and ownership

Thirty runs per week. Zero weekend noise. One expression. That's how you schedule a weekday-only job without overthinking it.