Arthur

Posted on Apr 9 • Originally published at goosekit.dev

What Is a Cron Job? A Beginner's Guide (Plus Free Visual Builder)

#webdev #javascript #tools #productivity

📅 April 9, 2026 · 10 min read ·
← All posts

What Is a Cron Job? A Beginner's Guide (Plus Free Visual Builder)

You need to send a daily digest email at 8am. Or back up your database every Sunday at midnight. Or purge expired sessions every hour. You could set an alarm on your phone, drink a coffee, open a terminal, and run the command manually. Or you could teach your server to handle it automatically.

That's what a
cron job
does. It's the simplest, most reliable scheduling tool Linux has offered for over forty years — and it remains the backbone of task automation on millions of servers worldwide.

This guide explains everything: what cron jobs are, how the syntax works (without the usual confusion), common mistakes that cost developers hours of debugging, real-world examples you can copy, and how to use a
free visual cron builder
so you never have to memorize the syntax again.

What is a cron job?

A
cron job
is a scheduled task on Unix-like operating systems (Linux, macOS, BSD). It's managed by
cron
, a background daemon (system service) that wakes up every minute, checks a file called a
crontab
(short for
cron table
), and runs any commands whose scheduled time matches the current minute.

The name "cron" comes from the Greek word
chronos
(χρόνος), meaning
time
. It was created by
Paul Vixie
in 1987, building on a concept that dates back to Version 7 Unix in 1979. Despite predating the World Wide Web by several years, cron remains the most widely used task scheduler on servers today.

Every user on a Unix system can have their own crontab — a simple text file where each line defines one scheduled task. You edit it with
crontab -e
, list it with
crontab -l
, and delete it with
crontab -r
.

💡 Quick example:
This crontab entry runs a database backup every day at 3:30am:

30 3 * * * /usr/local/bin/db-backup.sh > /var/log/db-backup.log 2>&1

Five cryptic characters, then a command. In sixty years, it's never stopped working reliably.

Cron syntax explained: the five fields

Every cron expression has
five space-separated fields
followed by the command to execute:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 7)
│ │ │ │ │

* * * * command-to-execute

Field

Range

Special values

Minute

0–59

—

Hour

0–23

—

Day of month

1–31

—

Month

1–12

Jan – Dec names

Day of week

0–7

0 = Sun, 1 = Mon, …, 7 = Sun. Mon–Sun names accepted.

Special characters you can use

Character

Meaning

Example

Any value — "every"

*
in minute = every minute

List separator

0,30
in minute = at minute 0 and 30

Range

9-17
in hour = from 9am to 5pm

Step values

*/15
in minute = every 15 minutes

@reboot

Run once at boot

@reboot /path/to/script.sh

@daily
(or
@midnight
)

Shorthand for
0 0 * * *

@daily /path/to/script.sh

@hourly

Shorthand for
0 * * * *

@hourly /path/to/script.sh

@weekly

Shorthand for
0 0 * * 0

@weekly /path/to/script.sh

@monthly

Shorthand for
0 0 1 * *

@monthly /path/to/script.sh

@yearly
(or
@annually
)

Shorthand for
0 0 1 1 *

@yearly /path/to/script.sh

Common cron expressions with explanations

Here are the most useful cron expressions you'll encounter in the wild. Each one includes a breakdown of exactly what it does:

Every minute.
Each field is
*
, meaning every possible value. This runs 1,440 times per day. Usually a mistake — you rarely need something running 1,440 times a day.

*/5 * * * *

Every 5 minutes.
The
*/5
in the minute field means "every value divisible by 5" — 0, 5, 10, 15, … 55. Useful for health checks, monitoring, and queue processors. Runs 288 times per day.

0 * * * *

Every hour, on the hour.
The
0
in the minute field means "at minute 0", and
*
in the hour field means "every hour." Runs 24 times per day.

0 */2 * * *

Every 2 hours.
Runs at 12:00am, 2:00am, 4:00am, 6:00am, etc. (every even-numbered hour). Runs 12 times per day.

0 8 * * *

Every day at 8:00 AM.
This is the classic "daily job" pattern — minute 0, hour 8, every day, every month, every weekday.

0 */6 * * *

Every 6 hours.
Runs at 12:00am, 6:00am, 12:00pm, 6:00pm. Four times per day. Perfect for rotating logs or syncing data from external sources.

0 9-17 * * 1-5

Every hour from 9am to 5pm, Monday through Friday.
The
9-17
range covers business hours, and
1-5
covers weekdays (1=Monday, 5=Friday). The classic "only during work hours" schedule.

30 4 * * 0

Every Sunday at 4:30 AM.
Minute 30, hour 4, day of week 0 (Sunday).

0 0 1 * *

First day of every month at midnight.
The
1
in day-of-month means "the first", and
*
in month means "every month."

0 2 15 * *

15th of every month at 2:00 AM.
Useful for monthly billing runs, invoice generation, or subscription renewals.

0 3 * * 1,4

Monday and Thursday at 3:00 AM.
The list
1,4
in the day-of-week field picks specific days. Great for weekly backup rotations.

Cron job mistakes that will bite you

Cron seems simple until it doesn't. Here are the mistakes that waste the most developer time:

The "AND vs OR" trap (most dangerous!)

When both
day-of-month
and
day-of-week
fields contain specific values (not
*
), cron uses
OR logic
— not AND. The job runs if
either
condition is true, not
both
.

⚠️ Example:

0 8 15 * 5
does NOT mean "the 15th when it's a Friday." It means "every 15th of the month OR every Friday at 8am." To get "only the 15th when it's a Friday," you'd need a wrapper script that checks the date inside the command.

Timezone confusion

Cron uses the
system timezone
. Most cloud servers (AWS EC2, DigitalOcean Droplets, Vercel, Render) default to
UTC
, not your local time. If you schedule "8 AM" thinking it's your local 8 AM but your server is on UTC, your job might run at midnight your time. Always verify with
date
on the server and add UTC offsets to your expressions.

No PATH environment

Cron runs with a minimal environment. The
PATH
variable is often just
/usr/bin:/bin
. Commands that work fine in your shell (like
node
,
npm
,
python3
, or
docker
) may fail with "command not found." Always use
absolute paths
or set PATH at the top of your crontab:

PATH=/usr/local/bin:/usr/bin:/bin
0 8 * * * /usr/local/bin/node /opt/app/daily-report.js

Concurrent overlapping runs

If a cron job takes longer than its interval, cron starts another instance anyway. A job scheduled every 5 minutes that sometimes takes 7 minutes will accumulate overlapping processes. Use a
lock file
or
flock
to prevent duplication:

*/5 * * * * flock -n /tmp/myjob.lock /path/to/script.sh

Silent failures (no output)

By default, cron emails output to the user's local mailbox. If you haven't set up mail delivery, errors go into a void. Always redirect output to a log file:

0 3 * * * /path/to/script.sh > /var/log/myjob.log 2>&1

The
2>&1
ensures both stdout and stderr go to the same file.

Missing the trailing newline

A crontab file
must end with a newline character
. If you hand-edit the file and forget, the last entry will be silently ignored.
crontab -e
usually handles this, but if you deploy crontabs via scripts, it's a common trap.

Day-of-week numbering confusion

Sunday is both
0
and
7
. Monday is
1
. But some cron implementations (like busybox cron) or other schedulers (like GitHub Actions cron, AWS EventBridge) use different conventions. Always double-check your platform's documentation.

Cron alternatives: when NOT to use cron

Cron is great, but not always the right tool:

Situation

Cron OK?

Better Alternative

Single server, simple schedule

✅ Yes

—

Multiple servers, no duplication wanted

❌ No

Distributed scheduler, leader election

Precise sub-minute scheduling

❌ No

Systemd timers, custom daemon

Cloud-native, auto-scaling

❌ No

GitHub Actions cron, AWS EventBridge, GCP Cloud Scheduler

Containerized ephemeral servers

❌ No

Kubernetes CronJobs, ECS Scheduled Tasks

Queue-based job processing

❌ No

BullMQ, Celery, Sidekiq

The visual cron schedule generator you actually need

Memorizing cron syntax is pointless. You don't need it in your head — you need a tool that translates your intent ("every Tuesday at 10pm") into the correct expression (
0 22 * * 2
) without second-guessing.

The
Cron Expression Builder on Goosekit
is exactly that — a free, client-side visual cron builder that lets you:

Click to build
your schedule — pick the frequency (minute, hourly, daily, weekly, monthly), set the values, and watch the expression appear in real time.

See the next 10 run dates
before you commit. The tool shows exactly when the job will execute so you catch timezone issues and OR-logic surprises
before
deploying.

Copy the expression
with one click — paste it straight into your crontab, your deployment config, or your GitHub Actions workflow.

Everything runs in your browser
— no data sent to any server, no signup, no account. Just open the page and use it.

How to use it

Open the Cron Builder
at
goosekit.dev/cron
.

Pick your frequency
— choose between every minute, every hour, daily, weekly, monthly, or "every N" (every 5 minutes, every 3 hours, etc.).

Set the values
— pick the specific minute, hour, day, or weekday using dropdown menus and checkboxes.

Check the preview
— the next 10 scheduled run times appear instantly. This is where you catch bugs like "oh, that runs on Saturday too?"

Copy the expression
— click copy and paste it wherever you need it.

💡 Pro tip:
Always check the next run preview. If you write
0 0 * * *
thinking it runs at midnight your time but your server is on UTC, the preview will immediately show you the mismatch.

You can also paste an existing cron expression into the tool to decode it — perfect for figuring out what an inherited crontab entry actually does.

Visual Cron Builder — free, no signup

Build cron expressions visually. Preview next run dates. 100% in your browser.

Open Cron Builder →

Cron in the modern stack

Cron isn't going anywhere. Even in 2026, it's the default scheduler on cloud VMs, CI/CD pipelines, and serverless platforms — but the syntax remains the same:

GitHub Actions
:
cron
triggers in workflows use standard Unix cron syntax (UTC only, 6-field with optional year).

AWS EventBridge Scheduler
: uses both cron and rate expressions, with timezone support.

Kubernetes CronJobs
: native cron syntax, plus
schedule:
and
successfulJobsHistoryLimit
.

Vercel Cron Jobs
: cron-like schedules in
vercel.json
for serverless functions.

Render, Railway, Fly.io
: all support cron-based scheduled tasks with the classic five-field syntax.

Systemd timers
: the modern Linux alternative to cron with dependency management and calendar-style scheduling.

Learn once, deploy everywhere. That's why understanding the cron expression format matters more than memorizing any one platform's wrapper around it.

Frequently Asked Questions

What is a cron job?

A cron job is an automated, time-based task on Unix-like systems that runs commands or scripts at scheduled intervals. It's managed by the cron daemon, which checks a user's crontab every minute and executes matching tasks.

What does * * * * * mean in cron?

It means "every minute of every hour of every day of every month on every day of the week." Each
*
wildcard matches all possible values in that field. It's rarely needed in practice.

How do I run a cron job every 10 minutes?

Use
*/10 * * * *
. The step value
/10
runs at minutes 0, 10, 20, 30, 40, and 50 — six times per hour, 144 times per day.

What are the most common cron job mistakes?

The big ones: (1) the OR logic trap when both day-of-month and day-of-week are set, (2) timezone confusion (server in UTC != your timezone), (3) missing PATH variable causing "command not found", (4) overlapping concurrent runs, and (5) silent failures with no output redirection.

Is there a free visual cron expression builder?

Yes.
Goosekit's Cron Builder
lets you click and select your schedule visually, see the next 10 run dates before committing, and copy the expression — all 100% in your browser, completely free, no signup required.

Can cron jobs run at the same time?

By default, yes. If a cron job takes longer than its interval, cron will start a second instance. Use
flock
or a lock file mechanism to prevent concurrent execution:
flock -n /tmp/lockfile /path/to/script.sh
.

Conclusion

Cron jobs are one of those tools you'll use for your entire career. The syntax looks cryptic at first, but once you understand the five fields — minute, hour, day of month, month, day of week — it becomes second nature. The real productivity hack is not memorizing it. It's using a visual builder that lets you focus on
when
you want something to run, not how to encode it.

Bookmark
goosekit.dev/cron
for your next cron expression. It's free, it runs in your browser, and the next-run preview will save you from the most common scheduling bugs.

DEV Community

What Is a Cron Job? A Beginner's Guide (Plus Free Visual Builder)

Top comments (0)