Linux Cron and Anacron: Scheduling, Missed Jobs and Verification

Cron runs commands on a recurring calendar schedule. Anacron is designed for periodic jobs on systems that may be off at the scheduled time. Neither makes a failed application job succeed, and the presence of a crontab entry does not prove it has run.

Understand the crontab fields

A user’s crontab has five time fields followed by the command: minute, hour, day of month, month and day of week. System crontabs and many /etc/cron.d files add a username field; copying that field into a user crontab changes what executes. Consult your installed implementation before using extensions.

# User-crontab template: 02:15 every day in the scheduler's timezone.
15 2 * * * /home/example/bin/verified-task >> /home/example/logs/task.log 2>&1

The account, executable and protected log directory are placeholders, not installed by this example. Use absolute paths and verify permissions, required environment and actual application behavior before scheduling. Cron usually has a smaller environment than an interactive shell; it does not automatically load your shell’s aliases or profile. Percent signs have special crontab meaning and must be handled according to the implementation.

When both day-of-month and day-of-week are restricted, common cron implementations match either field, not only their intersection. Step syntax operates within its field, not as an elapsed-time timer. Timezone and daylight-saving transitions can skip or repeat wall-clock times. Inspect the daemon’s actual configuration and do not infer its timezone from your browser.

When anacron helps

Anacron tracks periodic jobs with timestamps. An anacrontab entry has a period, delay, job identifier and command rather than cron’s five calendar fields. A numeric period is in days: 7 means a seven-day period, while 30 is not a calendar month. Some implementations support @monthly; check the local manual.

Anacron does not need a continuously running computer, but a missed task is not guaranteed to run immediately at boot. Its launcher, delay, allowed time window, power conditions, locks and machine uptime can affect execution. A machine that never runs the launcher cannot catch up. Avoid using force or timestamp-update options as “tests” without understanding that they can run work or alter scheduling state.

Create a safe operational schedule

1. Identify the correct account and task. Run the exact executable manually in a comparable environment with harmless test inputs.
2. Check existing cron, anacron, systemd timers and panel schedules to avoid duplicate execution.
3. Keep a private copy of existing entries before editing. Preserve unrelated jobs and configuration.
4. Choose a schedule appropriate to the application’s delay tolerance and runtime. Prevent overlap with a supported lock or the application’s own job mechanism.
5. Keep useful output and alert on failures or missing completions. Cron mail requires a working mail delivery setup and is not guaranteed for every successful run.
6. Observe an actual scheduled execution and validate its intended result. Removing a future entry does not stop a process already running.

Do not use root for an ordinary account task, hide all errors by default, or treat a successful scheduler launch as proof a backup or business operation completed. For web-hosting plans, prefer the supported account-level panel controls rather than assuming server-administrator access.

References: crontab manual and anacrontab manual.

Reviewed October 15, 2026. Schedule semantics and the illustrative entry were reviewed; no customer cron or anacron job was installed or run.