What Is a Cron Job? Scheduled Tasks Explained

A cron job is a task scheduled to run automatically at a fixed time or interval, without a person or another process triggering it manually. The name comes from cron, the time-based job scheduler built into Unix-like operating systems since the 1970s, and it’s still the standard vocabulary for “a thing that runs on a schedule” even in systems that don’t use the original Unix daemon at all.

The five-field schedule syntax

Classic cron schedules are written as five space-separated fields, each controlling a different unit of time:

* * * * *
│ │ │ │ │
│ │ │ │ └── day of week (0-6, Sunday = 0)
│ │ │ └──── month (1-12)
│ │ └────── day of month (1-31)
│ └──────── hour (0-23)
└────────── minute (0-59)

An asterisk means “every value” for that field. So 0 9 * * 1-5 means “at minute 0 of hour 9, every day of the month, every month, on weekdays 1 through 5” — in plain English, 9:00 AM on weekdays. A few more examples:

• */15 * * * * — every 15 minutes
• 0 0 1 * * — midnight on the first of every month
• 30 2 * * 0 — 2:30 AM every Sunday

Some cron implementations support shorthand strings like @daily, @hourly, or @reboot in place of the five fields. If you need to decode an existing expression or build one from scratch, our free cron expression parser turns cryptic syntax into plain English and shows the next run times, and the cron expression generator builds a valid expression from a simple form — both run entirely in the browser.

What cron jobs are used for

The common thread across cron use cases is repetitive work that doesn’t need a human to kick it off:

• Backups — dumping a database or snapshotting files on a nightly schedule.
• Report generation — compiling daily or weekly summaries and emailing them out.
• Cache and data cleanup — purging expired sessions, temp files, or stale rows.
• Health checks and monitoring — polling an endpoint periodically and alerting on failure, feeding into a broader observability setup.
• Data pipeline triggers — kicking off an ETL job at a fixed hour once upstream data is expected to be ready.

Where cron jobs run today

The original cron is a daemon on a single Linux or Unix host, reading job definitions from a per-user or system-wide crontab file. That model still exists, but most cron-scheduled work has moved to systems designed for distributed environments:

• Kubernetes CronJobs — a native Kubernetes object that creates a Job on a cron schedule, useful for running the same task consistently across a fleet without relying on a single always-on server. See how Kubernetes pods, deployments, and services fit together for the broader object model this builds on.
• Managed scheduler services — cloud providers offer scheduler products that trigger functions or containers on a cron expression, without you managing any server at all.
• CI/CD scheduled pipelines — tools like GitHub Actions support cron-triggered workflows directly in a pipeline definition, useful for nightly test runs or dependency update checks. See CI/CD with GitHub Actions for how scheduled workflows fit alongside push- and PR-triggered ones.

The syntax is nearly identical across all of these — learning classic five-field cron transfers directly to Kubernetes CronJobs and most CI schedulers.

Common pitfalls

Cron jobs are simple in concept but a few mistakes account for most production incidents:

• Timezone confusion. Traditional Unix cron runs in the system’s local timezone by default, which is a frequent source of off-by-several-hours bugs when servers are provisioned in UTC but schedules are written assuming local time. Kubernetes CronJobs and most cloud schedulers default to UTC — always check which one you’re targeting.
• Overlapping runs. If a job takes longer than its interval, a naive scheduler will happily start a second instance before the first finishes. Long-running jobs need explicit locking or concurrency policies to prevent this.
• Silent failures. A cron job that fails typically fails quietly — there’s no user watching a terminal. Route job output and exit codes into logging or alerting rather than assuming no news is good news.
• Missed runs after downtime. If the host or cluster is down when a job was due to fire, most schedulers simply skip that run rather than catching up. Design around this if a missed run matters (say, a daily billing job).

Cron vs event-driven triggers

Cron is the right tool when work needs to happen at a predictable time regardless of what else is going on. It’s the wrong tool when work should happen in response to something — a new file arriving, an order being placed, a queue depth crossing a threshold. For that, event-driven triggers (webhooks, message queues, or pub/sub systems) are a better fit, since they react immediately rather than waiting for the next scheduled tick. Many real systems use both: an event-driven pipeline for the hot path, and a cron job as a periodic reconciliation pass that catches anything the event path missed.

The takeaway

A cron job automates recurring work on a fixed schedule, defined by the classic five-field minute/hour/day/month/weekday syntax that’s carried forward largely unchanged from 1970s Unix into Kubernetes CronJobs and modern CI pipelines. The syntax is compact but easy to misread, so double-check timezone assumptions and test schedules with a parser before trusting them in production — and remember that anything time-sensitive rather than purely periodic is usually better served by an event-driven trigger.