---
title: "Cron job"
description: "A cron job is a single recurring task run by the cron daemon — backups, log cleanup, queue processing. See examples and best practices for reliability."
url: "https://nodea.io/en/glossary/cron-job"
lang: "en"
updated: "2026-07-13"
---

# Cron job

> A cron job is a single task scheduled for recurring execution by the cron daemon — one crontab line pairing a time pattern with a command, such as a nightly backup or an application scheduler tick.

A **cron job** is a single task registered for recurring, unattended execution by the [cron](https://nodea.io/en/glossary/cron) daemon on Unix-like systems. Concretely, it is one line in a [crontab](https://nodea.io/en/glossary/crontab): a five-field time pattern paired with a command — a shell script, a binary, or a curl call to a URL — that the system fires automatically whenever the pattern matches the clock.

## How a cron job works

The schedule fields cover minute, hour, day of month, month and day of week. Some realistic entries:

- *\* \* \* \* \* php /var/www/app/artisan schedule:run* — ticks a Laravel application scheduler every minute,
- *15 3 \* \* \* pg\_dump shop | gzip \> /backups/shop.sql.gz* — dumps a database daily at 03:15,
- *0 6 \* \* 1-5 /opt/bin/send-daily-digest.sh* — sends a digest on weekday mornings.

Each job runs with the permissions of the crontab's owner and in a stripped-down environment without your interactive shell settings. The two habits that prevent most cron mysteries are using absolute paths everywhere and redirecting output to a log file (*\>\> /var/log/job.log 2\>&1*) so failures leave evidence.

## Practical applications

Cron jobs are the workhorses of server maintenance and web application operations: database and file backups, log rotation, cache warming, clearing temp directories, syncing data with external APIs, renewing TLS certificates, dispatching newsletters, and recomputing reports during off-peak hours. Many platforms expect one: replacing WordPress's traffic-triggered wp-cron with a real system job makes scheduled posts reliable, and frameworks like Laravel or Symfony hang their entire scheduling layer off a single crontab entry.

On shared hosting you typically create jobs through the control panel; on a VPS you manage the crontab directly over [SSH](https://nodea.io/en/glossary/ssh). Regardless of environment, a few practices pay off:

- log every run and configure failure notifications (the *MAILTO* variable is the simplest option),
- lock long jobs against overlap with *flock* or an equivalent,
- schedule heavy work outside peak traffic windows,
- monitor execution externally — a heartbeat check that alerts when a job goes silent catches the failures your logs cannot report.

### How often can a cron job run?

Standard cron resolves to one minute — that is the shortest native interval. If you need sub-minute execution, either run a loop inside a script started every minute, use systemd timers with second-level precision, or let an application-level scheduler handle the fine granularity.

### What happens if a cron job is still running when the next run starts?

Cron happily starts a second instance, which can pile up processes and corrupt data. Guard long-running jobs with a lock, for example by wrapping the command in flock -n /tmp/job.lock, so overlapping executions exit immediately instead of stacking.

## Related

- [Cron](https://nodea.io/en/glossary/cron)
- [Crontab](https://nodea.io/en/glossary/crontab)
- [Backend](https://nodea.io/en/glossary/backend)
- [SSH](https://nodea.io/en/glossary/ssh)

---

Languages: [pl](https://nodea.pl/pl/slownik-pojec/cron-job.md)  
Site index: [llms.txt](https://nodea.io/en/llms.txt)