What are cron jobs and what can you do with them?

Cron jobs sound niche, but they quietly run most of the modern web. Backups, queue cleanups, scheduled emails, data imports, report generation, ... they're the digital equivalent of a backstage crew, keeping everything running on time.

Let's break down what they are, why they matter, and how to make sure they're actually working.

What are cron jobs and scheduled tasks?

A cron job is an instruction for your server to do something automatically at a specific time or interval. Think of it as an alarm clock for your infrastructure: at this time, run this script.

"Cron" comes from the Greek chronos, meaning time. On Unix-like systems (Linux, macOS, BSD) the scheduling daemon is called cron, and the things it runs are cron jobs. On Windows, the equivalent is called a "scheduled task". Same idea, slightly different wrapping.

Why are cron jobs useful for websites?

If your site has any real complexity, there's probably a cron job (or a few) doing important work in the background. Typical examples:

• Take a nightly database backup
• Clear expired sessions or cached data
• Send scheduled emails or notifications
• Import fresh data from an external API
• Generate weekly or monthly reports
• Regenerate sitemaps or ping search engines

They take repetitive, time-sensitive tasks off your plate and make sure those tasks happen reliably, at the right moment, without someone having to remember.

Real-world examples

A nightly database backup

You run an online store. You don't want to remember to back up the database every night (you won't). A cron job can do it at 2:00 AM and drop a fresh copy in off-site storage:

0 2 * * * /usr/bin/mysqldump -u user -pPassword dbname > /backups/db.sql

The five numbers at the start look cryptic at first, but once you recognize them they're easy to read.

A weekly newsletter batch

Have a script that builds your newsletter and sends it at noon every Friday? One line in crontab and done. (Most marketing tools can do it for you, but a cron job is a fine fallback for internal emails.)

Cleaning up expired shopping carts

Abandoned cart data piling up? A job that runs every hour and deletes entries older than 24 hours keeps things tidy.

Weekly analytics digest

Have a script that crunches traffic stats and emails a report to your team? Schedule it once a week and stop thinking about it.

How are cron jobs configured?

On Linux, cron jobs live in a crontab file (short for "cron table"). A single line pairs a schedule with a command. Here's what one looks like:

30 3 * * 1 /home/user/scripts/weekly_backup.sh

This runs weekly_backup.sh every Monday at 3:30 AM.

The five numbers map to:

minute       (0 - 59)
hour         (0 - 23)
day of month (1 - 31)
month        (1 - 12)
day of week  (0 - 6, where 0 is Sunday)

On Windows, Task Scheduler gives you a graphical interface instead of a text file. The concept is identical.

"Silent failures" are the real enemy

Setting up a cron job is easy. Knowing it's still doing its job in six months is the hard part.

Jobs fail quietly all the time. An API stops responding. A file path changes during a deploy. A new server permission breaks the script. The job just... stops, and you don't notice until the missing data, the backup-less recovery, or the silent newsletter nobody received.

That's the "silent failure" problem, and it's exactly the kind of thing a cron job is supposed to prevent in the first place.

Why monitoring your cron jobs matters

You don't want to rely on "I assume it's still working" for code that handles your backups.

Cron jobs often own the invisible-but-critical parts of your operation: backups, data syncs, billing runs, cleanup. When they stop, the consequences range from mildly annoying (the Friday report didn't go out) to genuinely bad (there's no backup to restore from).

Lucky for you, you're on a website monitoring service that can watch your cron jobs too. Oh Dear monitors cron jobs and scheduled tasks alongside everything else, and lets you know if:

• A job doesn't run on time
• A job fails
• The output contains errors or a specific string you're watching for

So you hear about problems before your users (or your boss) do.

Tips for managing cron jobs

• Log the output of every job, especially when it talks to an external API.
• Pick sane schedules. Test the timing so you don't overload the server during peak hours.
• Avoid overlapping runs. If a job can take longer than its interval, use a lock or flock so instances don't stack.
• Document what each job does, so future-you (or the next person on the team) isn't reading a cryptic line in crontab at 3 AM wondering what it means.
• Monitor them centrally so you're not grepping logs on a dozen servers to figure out what ran.

When to use a cron job (and when not to)

Cron jobs are perfect for predictable, recurring work. They're not the right tool for event-driven tasks like processing user uploads or sending welcome emails the moment someone signs up. For that, use a background job queue (Laravel Horizon, Sidekiq, Celery, etc.).

Rule of thumb:

• Predictable and recurring? Cron job.
• Triggered by user action? Background worker.

If you're already running cron jobs in production, make sure you know they're actually running. Your first 30 days of peace of mind are on us, no credit card needed.