Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsA cron job is a command that Linux runs automatically on a schedule. The cron or crond daemon checks stored schedules every minute and starts commands whose time fields match. On a VPS, cron is useful for backups, certificate checks, cleanup scripts, reports and other repeatable maintenance that should run without an interactive login.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide explains the five-field schedule, the exact commands to install and verify a job, logging and security practices, daylight-saving behavior, failure diagnosis, and when a systemd timer is a better fit.
As an Amazon Associate I earn from qualifying purchases.
What a cron job is and how it runs
Linux describes crond as a daemon that executes scheduled commands. A crontab is the text table that tells the daemon which command to run and when. The daemon examines the installed tables and checks each entry for the current minute. If the schedule matches, it launches the command under the account that owns that table.
A normal user crontab contains a schedule followed by a command. The system-wide /etc/cron.d format adds a username between the schedule and the command, because one file can contain jobs for several accounts. User crontabs and system files are therefore similar but not interchangeable.
#1 Best Overall
What happens after you save a crontab
When you save a table edited with crontab -e, cron normally notices the change and reloads it; restarting the daemon is not normally required. The installed table can be displayed with crontab -l. Do not edit spool files directly: their location and ownership are implementation details, and direct edits can be rejected or corrupted.
Where output goes
If a command writes to standard output or standard error, cron can mail that output to the table owner, and cron activity can also be recorded in syslog or the system journal. For production work, make the destination deliberate: redirect both streams to a log you can read, or set an appropriate MAILTO value and monitor the resulting mail. A job that runs silently is difficult to distinguish from a job that never ran.
Time zones and daylight-saving changes
Cron evaluates the schedule in the system’s local time unless the distribution or configuration says otherwise. During a daylight-saving transition, a local time that does not exist is skipped. When an hour occurs twice, a job scheduled in that repeated hour can run twice. Use a clearly chosen server time zone and design non-idempotent tasks so a duplicate invocation cannot damage data.
Prepare the VPS before scheduling
Identify the service name
Distribution naming differs. Debian and Ubuntu systems commonly use cron; other Linux images may use crond. Check both the service status and the package’s logs using the name your image provides:
sudo systemctl status cron
sudo systemctl status crondOne of those commands may report that the unit does not exist; that is a naming difference, not proof that scheduling is unavailable. Install or enable the distribution’s cron package if neither service is present, then confirm that the daemon is active before testing a job.
Choose the account that should run the command
A user’s table runs with that user’s permissions. Use the least-privileged account that can complete the task. Reserve root’s crontab for work that genuinely needs root access, such as operations on protected system files. Running everything as root turns a script mistake or an unsafe file path into a system-wide incident.
Check paths and write permissions
Cron starts commands with a smaller environment than an interactive shell. The current directory, PATH, language settings and application-specific variables may differ from what you see in a terminal. Use absolute paths for interpreters, scripts, configuration files and log files. Make sure the selected account can execute the script and write wherever the command sends output; a root-owned directory such as /var/log may not be writable by an ordinary user.
Create and install a cron job
- Log in to the VPS as the account that should own the job.
- Open that account’s table with
crontab -e. The editor may ask you to choose an editor the first time. - Add one complete schedule line. For example, this runs a backup script every day at 02:15 and appends both output streams to a log:
15 2 * * * /usr/local/bin/backup.sh >>/var/log/backup.log 2>&1- Save the file and exit the editor. Cron detects the changed table automatically.
- Confirm that the intended account now has the entry:
crontab -lThe script itself should have a valid shebang, executable permission and a final newline. For example:
#!/bin/sh
# commands for the backup
Then make it executable with a command such as chmod 750 /usr/local/bin/backup.sh, choosing ownership and permissions appropriate to the data it handles.
Understand the five cron fields
A standard crontab line has five time fields followed by the command. The fields are evaluated using these ranges:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Field | Allowed values | Meaning | Example |
|---|---|---|---|
| Minute | 0–59 | Minute within the hour | 15 means at minute 15 |
| Hour | 0–23 | Hour in 24-hour notation | 2 means 02:00–02:59 |
| Day of month | 1–31 | Calendar day | 1 means the first day |
| Month | 1–12 | January through December | 7 means July |
| Day of week | 0–6 | Sunday is 0; implementations may also accept 7 for Sunday | 1 means Monday on the usual numbering |
An asterisk means every permitted value. Commas make a list, hyphens make an inclusive range, and */n creates steps within a field.
| Pattern | Meaning |
|---|---|
0,30 |
At minute 0 and minute 30 |
9-17 |
Every value from 9 through 17 |
*/10 |
Every 10 units in that field |
1-5 in the day-of-week field |
Monday through Friday on the conventional numbering |
For schedules that constrain both day of month and day of week, consult the crontab(5) manual on the VPS to confirm the implementation’s matching rule before relying on an edge case. Keep schedules easy to read rather than combining unnecessary lists and ranges.
Common schedule examples
| Purpose | Crontab line |
|---|---|
| Every five minutes | */5 * * * * /absolute/path/check.sh |
| At 03:00 every Sunday | 0 3 * * 0 /absolute/path/weekly.sh |
| At 01:30 on the first day of each month | 30 1 1 * * /absolute/path/monthly.sh |
| Weekdays at 08:00 | 0 8 * * 1-5 /absolute/path/workday.sh |
Convenience nicknames
Linux cron implementations commonly provide nicknames such as @reboot, @hourly, @daily, @weekly, @monthly and @yearly. They are readable alternatives when you do not need a particular minute. Their exact startup and calendar behavior is defined by the local manual, so check man 5 crontab on the VPS.
Make scheduled commands reliable
Use an explicit environment
Do not assume the interactive shell’s PATH, home directory or application variables exist. Call programs by absolute path, and define required variables near the top of a script or in the crontab. If a task needs a virtual environment, working directory or credentials, activate or select them explicitly inside the script. Keep secrets out of world-readable crontabs and logs.
Quote data and paths safely
Quote paths and arguments that contain spaces or shell metacharacters. Prefer a small, version-controlled script over a long shell expression embedded in the crontab. This makes error handling, testing and permission review much easier.
Capture success and failure
Redirect standard output and standard error deliberately. The backup example uses >> to append and 2>&1 to put errors in the same file. Choose a log location with suitable ownership and arrange rotation so an unattended job cannot fill the disk. If you rely on cron mail instead, set MAILTO and verify that local delivery is configured.
Prevent overlapping runs
A job that takes longer than its interval can overlap with its next invocation. Use an appropriate locking strategy for long-running work, such as a lock file or the distribution’s locking utility, and decide whether a second run should wait, exit or be skipped. The lock must be removed safely when the process terminates unexpectedly, and the protected operation should be safe to retry.
Recommended Free Tools
Account for reboots and time changes
An @reboot entry is useful for a simple startup command, but it does not provide the dependency ordering, readiness checks or resource controls of a service manager. For calendar jobs around daylight-saving changes, document the server time zone and whether a duplicate execution is acceptable.
Verify a job without waiting blindly
- Display the table for the intended account with
crontab -l. Running this as the wrong user shows the wrong table. - Run the exact command manually as that account, using the same absolute paths and environment. Fix script errors before blaming cron.
- Check the daemon state with
systemctl status cronorsystemctl status crond, according to the VPS distribution. - Inspect the distribution’s cron log or system journal for evidence that cron attempted the command.
- Read the redirected log file or cron mail. Distinguish “cron launched it” from “the application completed successfully”; only the command’s own output can establish the latter.
For a safe smoke test, temporarily schedule a command that appends the current date to a user-writable file, wait for the next matching minute, confirm the line appeared, and remove the test entry. Do not use a test that changes production data.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot a job that did not run
1. The entry is missing or belongs to another user
Run crontab -l as the account that should execute the command. If the job was intended for root, inspect it with sudo crontab -l. A line placed in one account’s table will not appear in another account’s table.
Best Value
- New
- Mint Condition
- Dispatch same day for order received before 12 noon
- Guaranteed packaging
- No quibbles returns
2. The schedule is not what you intended
Read the five fields from left to right and verify the server’s local time. Check month and weekday numbering, ranges and step expressions. Confirm that a local time affected by daylight-saving rules is not skipped or repeated.
Free tools Windows power users keep installed
One-click scans. No signup required.
3. The daemon is inactive
Check the appropriate cron or crond unit and start or enable it using the VPS distribution’s normal service procedure. Then inspect its log for parse errors or launch failures.
4. The command works in a shell but not under cron
Replace relative paths with absolute ones, define missing environment variables, set the working directory explicitly and call the intended interpreter. Verify executable bits, ownership, the shebang and access to every input and output file.
5. The table is partially ignored
Check formatting carefully. A malformed line, an invalid field or a missing final newline can make a crontab partially broken; the crontab(5) manual specifically warns about a missing terminating newline. Reopen the table with crontab -e, correct the line and save it again.
6. The command ran but produced no visible result
Inspect the redirected log, local mail, syslog or journal. Check whether the account could write the destination and whether the script itself suppresses errors. Add explicit error messages and nonzero exits so failures are observable.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →7. A long job runs twice or collides with itself
Measure its normal duration, compare that with the interval and add a locking strategy. If the task needs ordering with mounts, network readiness or another service, move it to a systemd service and timer instead of making cron coordinate those dependencies.
Cron or a systemd timer?
Cron remains a compact, portable choice when a simple command must run on many Linux distributions. Native systemd timers are better when the schedule is part of a managed service and you need systemd’s dependency ordering, service state, journal integration, calendar expressions or resource controls.
| Decision factor | Cron | Systemd timer |
|---|---|---|
| Portability | Available across a wide range of Linux VPS images with familiar five-field syntax | Requires a systemd-based image and unit files |
| Schedule language | Five fields, lists, ranges, steps and common nicknames | Calendar expressions and timer-specific options |
| Dependencies | Does not model service ordering directly | Can order and bind a timer to service units and system targets |
| Logs and inspection | Mail, syslog and distribution-specific cron logs | systemctl status/list commands and the journal |
| Resource and failure controls | Must be implemented by the script or surrounding tools | Inherited systemd service controls can define restart, limits and execution context |
Debian’s systemd-cron tooling can translate cron entries into systemd timer and service units. On systems using that approach, systemctl list-timers shows timer activity and journalctl -u <unit> provides service evidence. Package behavior and generated unit names depend on the VPS distribution, so inspect the actual units rather than assuming a universal name.
Quick Recap
Choose cron when
- The task is a straightforward command with a conventional calendar schedule.
- You need the same portable format on different Linux distributions.
- The script can handle its own retries, locking, logging and error reporting.
Choose a systemd timer when
- The task depends on another service, mount, network target or startup ordering.
- You need journal-centered logs and clear service status.
- You need systemd execution limits, restart behavior or richer calendar rules.
A practical VPS checklist
- Confirm whether the daemon is named
cronorcrond, and verify that it is active. - Edit with
crontab -e; inspect withcrontab -l; never edit spool files directly. - Validate all five fields and the server’s local time zone.
- Use absolute paths, an explicit interpreter and required environment variables.
- Run with the least privilege that completes the task.
- Ensure the script is executable, has a valid shebang and ends with a newline.
- Redirect output or configure
MAILTO; inspect logs, mail and the journal. - Add locking for jobs that might overlap.
- Test the exact command manually as the scheduled account.
- Use a systemd timer when dependency ordering, service state or resource controls matter.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
