Servers
Scheduled tab
Jobs that run on a timetable — what they are, when they next run, and what they actually did.
Servers run things on a timetable: a nightly database backup, a certificate renewal, a log cleanup, a report email. This tab shows all of them in one place — and, unusually, shows you whether they actually worked.
Where scheduled jobs hide
The tab gathers all of these, because a job can be in any of them:
| Source | What it is |
|---|---|
| User crontabs | Jobs owned by a particular user |
/etc/crontab | The system-wide table |
/etc/cron.d | Files dropped in by installed software |
cron.hourly / daily / weekly / monthly | Scripts run on those cycles |
| systemd timers | The modern replacement for cron |
Use All sources to see everything at once.
Reading a job
| Column | Meaning |
|---|---|
| Schedule | Written in plain English — "Every day at 02:00" — not just 0 2 * * * |
| Next | When it will next run |
| Last | When it last ran |
| Command | What it runs |
| Runs as | Which user it runs as. This matters: it decides what the job may touch |
| Where | Which file it came from |
What cron actually logged
Select a job and you get what the system recorded when it ran. This answers the question that matters: "my backup is scheduled — but is it running?"
A job that has been failing silently for six months looks identical, in the schedule list, to one that works. The log is the difference.
Run now
Runs the job immediately, using cron's own environment.
That detail is the point. The classic cron bug is a job that works when you run
it by hand and fails on schedule, because cron runs with a minimal PATH and
no profile loaded. Run now reproduces cron's environment, so if it works
here it will work tonight.
MAILTO and PATH
- MAILTO — where cron sends output. If it is empty, failures go nowhere, which is how a broken backup stays unnoticed.
- PATH — the very short list of places cron looks for commands. Jobs should
use full paths like
/usr/bin/mysqldumprather thanmysqldump.
Editing
You can edit crontabs directly. A backup of the file is taken automatically before your change is written, so a mistake is recoverable.
Cron syntax is unforgiving — five fields, in the order minute, hour, day of month, month, day of week. The plain-English translation shown next to each job is the quickest way to check you wrote what you meant.
What to check on a server you inherited
- Is there a backup job? Does its log show it succeeding?
- Is there a certificate renewal job (
certbotor similar)? - Does anything run as
rootthat you do not recognise? Unexplained root cron jobs are a classic sign of a compromised server.
Guided tasks What runs on a schedule? and Are my backups working? do this review for you and report in plain words. See Guided tasks.
Permissions
Operator and above can edit jobs and run them now. Viewers can read. Everything is recorded in the Activity log.