---
title: "Crontab"
description: "Crontab is both the file holding a user's cron schedule and the command to manage it. Learn crontab -e, -l and -r, entry syntax and environment variables."
url: "https://nodea.io/en/glossary/crontab"
lang: "en"
updated: "2026-07-13"
---

# Crontab

> Crontab is the per-user file that stores cron's job schedule, and the command used to view and edit it safely (crontab -e, crontab -l). Every entry pairs a five-field time pattern with a command.

**Crontab** — short for *cron table* — is the file that stores the schedule of jobs executed by the [cron](https://nodea.io/en/glossary/cron) daemon, and simultaneously the command-line utility used to manage that file. Every account on a Unix-like system can own its personal crontab; alongside them live the system-wide */etc/crontab* and package drop-ins under */etc/cron.d*.

## How crontab works

You never edit the stored file by hand — the spool location (typically */var/spool/cron/crontabs/*) is private to the daemon. Instead, the *crontab* command mediates all changes:

- *crontab -e* — open your schedule in an editor; syntax is validated on save,
- *crontab -l* — print the current entries,
- *crontab -r* — remove the entire schedule, instantly and without confirmation,
- *crontab -u alice -e* — edit another user's schedule (root only).

Each non-comment line is one [cron job](https://nodea.io/en/glossary/cron-job): five time fields followed by the command. Beyond jobs, a crontab may define environment variables. *MAILTO* tells cron where to email each job's output and errors, *PATH* fixes the notoriously minimal default search path, and *SHELL* selects the interpreter. Lines starting with *#* are comments — use them generously, because six months later nobody remembers what *sync2.sh* was for.

## Practical applications

The crontab is effectively the automation manifest of a server account: reading it tells you what backups run, when logs rotate, which application schedulers tick and what data syncs happen overnight. On a VPS you manage it directly over [SSH](https://nodea.io/en/glossary/ssh); shared hosting panels such as cPanel, DirectAdmin or Plesk provide a form-based editor that writes to the same underlying file.

Habits that save real pain:

- export a copy regularly (*crontab -l \> crontab.backup*) or keep the schedule in version control — *crontab -r* sits one keystroke away from *crontab -e* and deletes everything,
- set *MAILTO* or redirect job output to log files so failures are visible,
- comment every entry with its purpose and owner,
- after any edit, confirm in the system log that the job fired at the expected time.

Administrators of multi-user machines can additionally control who may use crontabs at all via */etc/cron.allow* and */etc/cron.deny*.

### What is the difference between a user crontab and /etc/crontab?

User crontabs are managed with the crontab command, run as their owner, and have six fields per line (time plus command). The system-wide /etc/crontab and files in /etc/cron.d are edited directly by root and include an extra field naming the user account each job should run as.

## Related

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

---

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