A Linux server often needs to perform work when nobody is logged in. Backups, cleanup jobs, reports, certificate checks, database maintenance, and monitoring scripts may need to run every hour, every night, or at a particular time after startup.
Two common Linux mechanisms for this are cron and systemd timers. Both can start work automatically, but they organize scheduling and execution in different ways.
Cron connects a time expression to a command. A systemd timer normally connects a schedule to a managed service. Understanding that difference makes it much easier to choose the right tool and diagnose a scheduled job that did not behave as expected.
Cron is a traditional Linux scheduler that executes commands according to entries in a crontab. It is compact and works well for straightforward recurring jobs.
systemd timers schedule the activation of systemd units, usually services. They integrate scheduling with service configuration, status inspection, dependencies, and the systemd journal.
For a simple recurring command, cron may be enough. For a server task that benefits from explicit service management, structured logging, dependency handling, or missed-run behavior, a systemd timer can be a better fit.
- What a Linux scheduler actually controls.
- How cron expressions define recurring schedules.
- How a systemd timer activates a service.
- Why scheduled commands can behave differently from terminal commands.
- How to inspect existing schedules safely.
- How to diagnose a task that did not run correctly.
- What Does a Linux Task Scheduler Actually Do?
- How Cron Schedules Linux Commands
- Minute
- Hour
- Day of Month
- Month
- Day of Week
- Command
- How to Inspect Cron Jobs Safely
- How systemd Timers Work
- Calendar Timers and Interval Timers
- OnCalendar
- OnBootSec
- Cron vs systemd Timers: Key Differences
- Why Scheduled Commands Fail When They Work in a Terminal
- Inspect Linux Scheduling Without Changing the System
- Check the Current User’s Cron Schedule
- List systemd Timers
- Inspect One Existing Timer
- Read the Timer Configuration
- Inspect the Associated Service
- What Happens If the Machine Was Off?
- How to Troubleshoot a Scheduled Task
- Five Mistakes to Avoid
- Check Your Understanding
- 1. What is the main difference between cron and a systemd timer?
- 2. Does an active systemd timer prove that its service succeeded?
- 3. Why can a command work manually but fail when scheduled?
- 4. What does OnCalendar describe?
- 5. What is Persistent used for?
- 6. A scheduled backup produced no usable file. What should you check?
- Scheduling Is About More Than Choosing a Time
- Official References
What Does a Linux Task Scheduler Actually Do?
A scheduler answers two separate questions: when should work begin, and what should run?
The schedule is not the work itself. A backup script, for example, contains instructions for copying or archiving data. The scheduler simply decides when that script should be started.
This distinction matters because a schedule can be configured correctly while the underlying program still fails.
Defines when the task should be triggered.
Starts the configured command or managed service.
The program succeeds, fails, or continues running.
Imagine a daily report generator scheduled for 02:00. If the report is missing the next morning, several different things could have happened.
The scheduler may not have been active. The task may never have started. The command may have started and failed. Or the command may have succeeded but written its output somewhere unexpected.
Good troubleshooting separates those possibilities instead of treating “the scheduled task failed” as one problem.
How Cron Schedules Linux Commands
Cron is a time-based scheduling system. A cron daemon evaluates configured schedules and launches commands when their time expressions match.
Individual users can maintain their own crontabs. The crontab command is commonly used to inspect or edit those entries.
A standard user crontab entry contains five scheduling fields followed by the command.
MIN HOUR DAY MONTH WEEKDAY COMMANDFor example, this entry schedules a command for 02:30 every day:
30 2 * * * /usr/local/bin/daily-reportThe first field represents the minute and the second represents the hour. The remaining three scheduling fields describe the day of the month, month, and day of the week.
An asterisk means every permitted value for that field.
The command in this example is illustrative. Linux does not necessarily provide a program called daily-report.
Minute
When within the hour the command should run.
Hour
Which hour of the day should match.
Day of Month
Which calendar dates should match.
Month
Which months should match.
Day of Week
Which weekdays should match.
Command
The command or program that cron should execute.
How to Inspect Cron Jobs Safely
Before editing anything, check whether the current user already has a crontab.
crontab -lThis command lists the current user’s installed crontab. If no crontab exists, the command may report that none is installed.
It does not prove that the machine has no scheduled cron work. Other users and system-wide cron configuration may contain additional jobs.
Use crontab -e when you intentionally want to edit the current user’s schedule.
The crontab -r command removes the user’s crontab. It is not a command for removing one selected line from the schedule.
How systemd Timers Work
A systemd timer is a unit that activates another systemd unit according to a schedule.
A file ending in .timer commonly activates a corresponding .service unit.
The timer describes when the work should start. The service describes what should run and under which execution conditions.
Defines the calendar or elapsed-time trigger.
Defines the command and its execution environment.
Performs the real task and produces a result.
This separation connects scheduling to the broader systemd service-management model.
The service can define its own user, working directory, environment, dependencies, and other execution settings. Its state can be inspected with systemctl, while available journal messages can be queried with journalctl.
If you have not worked with unit files before, first read the Servers Academy guide to creating a systemd service and writing a unit file.
Calendar Timers and Interval Timers
Systemd can describe scheduled execution in more than one way.
A calendar timer uses wall-clock expressions. For example, OnCalendar=daily describes a recurring daily schedule.
An elapsed-time timer can schedule work relative to another event. For example, OnBootSec=10min describes a trigger relative to system startup.
OnCalendar
Useful when work should run according to a recognizable calendar schedule.
OnBootSec
Useful when execution should occur a certain amount of time after boot.
These concepts are not identical. Calendar timers are based on wall-clock time, while elapsed-time directives can use monotonic timing.
Timer activation also should not automatically be interpreted as exact to the second. Systemd can coalesce timer events according to timer accuracy settings.
Cron vs systemd Timers: Key Differences
Both mechanisms can schedule recurring Linux work. The biggest difference is how scheduling is connected to execution and management.
Cron is not inherently unreliable, and systemd timers are not automatically superior.
A short personal maintenance command may be easy to express in a crontab. A recurring server workload with explicit dependencies, permissions, logging, and service-management requirements may benefit from a timer and service pair.
Why Scheduled Commands Fail When They Work in a Terminal
One of the most common scheduling mistakes is assuming that an automated command runs inside the same environment as your interactive terminal.
Usually, it does not.
A cron job may receive a limited environment and may begin in a different working directory from the one you used while testing manually.
A systemd service also receives its execution environment from its service configuration and manager. It does not automatically inherit your terminal session.
Consider a script that works after you manually enter its project directory:
cd /home/student/reports
./generate.shIf the script relies on relative file paths, scheduled execution may fail because the process starts from another directory.
A more reliable automated task explicitly defines the required working directory or uses appropriate absolute paths.
The same principle applies to environment variables and executable lookup. The Servers Academy lesson on Linux environment variables and PATH explains why values from one shell do not automatically appear in another process.
When an automated task fails, investigate the environment in which it actually started. Do not assume it received the same PATH, variables, working directory, or permissions as your interactive shell.
Inspect Linux Scheduling Without Changing the System
The following exercise uses read-only inspection commands. It does not install cron jobs, enable timers, restart services, or require you to modify system configuration.
Check the Current User’s Cron Schedule
crontab -lLook for recurring entries and identify their scheduling fields and commands. An empty user crontab does not mean that no scheduled jobs exist elsewhere on the system.
List systemd Timers
systemctl list-timers --allLook at the available timer units and their scheduling information. Exact output columns can vary with the installed systemd version and terminal configuration.
Inspect One Existing Timer
Choose a real timer name from the previous output and replace the example below.
systemctl status example.timerThis tells you about the timer. It does not by itself prove that the associated service completed successfully.
Read the Timer Configuration
systemctl cat example.timer
Look for directives such as OnCalendar or OnBootSec. Also check which unit the timer activates rather than assuming the target from its name.
Inspect the Associated Service
systemctl status example.serviceThe service state tells you what happened to the workload after the timer triggered it.
journalctl -u example.service -n 30 --no-pagerJournal visibility depends on system permissions, so an unprivileged account may not be able to read every entry.
What Happens If the Machine Was Off?
Suppose a machine is powered off during its normal maintenance window.
A traditional cron schedule does not necessarily replay the missed execution when the machine comes back online. Some Linux environments use additional mechanisms such as anacron for periodic work that may have been missed during downtime.
Systemd calendar timers can provide a different mechanism through the Persistent setting.
When persistence is enabled, a timer can trigger after activation when at least one scheduled occurrence was missed while the timer was inactive.
This should not be interpreted as every missed occurrence being replayed independently, and it does not guarantee that the service itself will succeed.
A scheduler can successfully trigger a backup program that later fails. For important maintenance tasks, verify the resulting data and test recovery separately from the scheduling mechanism.
How to Troubleshoot a Scheduled Task
Start by identifying which part of the execution chain failed.
First, confirm that the schedule exists. Then determine whether the scheduler was active at the expected time.
Next, check whether the command or service actually started.
If it started, investigate its exit status, output, permissions, environment, working directory, and dependencies.
For systemd-managed work, inspect both the timer and the associated service. The timer tells you about scheduling and activation; the service tells you about execution.
For cron, inspect the configured command and the logging or output mechanisms available on the installed system.
Do not repeatedly change the schedule until you know whether the failure belongs to scheduling or to the program being executed.
Five Mistakes to Avoid
A schedule expresses intent. Verify that execution actually occurred and inspect the program’s result.
A scheduled process may start somewhere different from the directory you used during manual testing.
Scheduled processes have their own execution environment. Configure required values explicitly.
An active timer can trigger a service that subsequently fails. Inspect both parts.
Decide what should happen when a scheduled occurrence is missed while the machine is unavailable.
Check Your Understanding
Use these questions to verify that you understand the execution model rather than simply memorizing commands.
1. What is the main difference between cron and a systemd timer?
AnswerCron schedules commands through crontab entries. A systemd timer schedules activation of a managed unit, commonly a service.
2. Does an active systemd timer prove that its service succeeded?
AnswerNo. Timer activation and service execution are separate. Inspect the associated service and its available logs.
3. Why can a command work manually but fail when scheduled?
AnswerThe scheduled process may have different environment variables, permissions, executable paths, or a different working directory.
4. What does OnCalendar describe?
AnswerIt defines a calendar-based schedule for a systemd timer using wall-clock time.
5. What is Persistent used for?
AnswerFor relevant calendar timers, it can provide catch-up activation when a scheduled occurrence was missed while the timer was inactive.
6. A scheduled backup produced no usable file. What should you check?
AnswerCheck the complete chain: schedule, activation, program execution, exit status, output destination, and the validity of the resulting backup.
Scheduling Is About More Than Choosing a Time
Cron and systemd timers both automate Linux work, but they organize scheduling and execution differently.
Cron expresses a schedule and command compactly. Systemd timers connect scheduling to managed units and the wider service-management system.
The most useful operational habit is to verify what actually ran, not merely what was configured to run.
Understand the schedule, inspect the execution environment, and verify the result before trusting any automated maintenance task.
Official References
For implementation details and options beyond this lesson, consult the upstream documentation for the scheduler installed on your system.
