Cron jobs: how to schedule them and know they worked

What is a cron job?

On Unix-like systems, cron is a time-based scheduler. A cron job is a command in a crontab that cron launches when its schedule matches. Typical jobs generate reports, clear temporary files, back up data, or synchronize inventory. A web application can also expose a protected HTTPS endpoint that an external scheduler calls at the chosen time.

Scheduling answers “when should this start?” It does not, by itself, prove that the command finished, that a backup is restorable, or that all expected records were synchronized. For important work, record the run, monitor missed starts, and verify the result separately.

How to read a five-field cron expression

A common user crontab line has five time fields followed by a command. The fields are minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–7, with Sunday often 0 or 7). A star means every allowed value; a comma is a list; a hyphen is a range; a slash is a step.

minute hour day-of-month month day-of-week command
0      2    *            *     *           /usr/bin/php /srv/app/jobs/backup.php

Here, 0 2 * * * starts at 02:00 every day in the scheduler’s configured time zone. Cron variants differ: some cloud schedulers have a seconds field or use different day-of-week rules. Check the syntax of the platform that actually runs your job.

Easy-to-miss detail: in traditional Vixie-style cron, restricting both day of month and day of week usually means either field can match. 0 9 1 * 1 can run on the first of the month and on Mondays. If you mean “only when the first is Monday,” add that condition in the command or use a scheduler whose semantics you have verified. See the Linux crontab manual for details.

Useful cron job examples

These are schedule examples, not promises of exact wall-clock behavior. Daylight saving transitions, system time zone, overlapping runs, and a stopped host can affect execution. Put the chosen time zone and expected completion window in your runbook.

Set up and test a server cron job

1. Write a command that is safe to run again after a partial failure. Use absolute paths to the interpreter, script, and files it needs.
2. Run that exact command manually as the account cron will use. Check its exit code, output, and the actual business result.
3. Install the schedule with crontab -e for the intended account. A typical entry is 0 2 * * * /usr/bin/php /srv/app/jobs/backup.php.
4. Capture errors in a protected log or your normal logging system. Keep passwords, tokens, and private URLs out of public logs and repository files.
5. Trigger one controlled test, then confirm the resulting artifact or record. Simulate a safe failure and confirm your alert reaches the owner.

Cron has a smaller environment than an interactive shell. Set required environment variables deliberately, use absolute paths, and do not assume a particular working directory. For long jobs, plan for timeouts and overlapping starts. For changes that charge, send, or delete, use idempotency keys or a lock appropriate to the workload.

Why a cron job can fail silently

• It never started: the host was down, the crontab was installed under another user, the time zone was wrong, or the schedule was malformed.
• It started but failed: permissions, missing environment values, network errors, or a non-zero exit code stopped the command.
• It looked successful: the process exited zero or an endpoint returned HTTP 200, but the backup file, inventory update, or report was missing or stale.
• It ran twice: a previous run overlapped the next scheduled start, or a retry repeated a side effect.

Logs answer what the process attempted. A cron job monitor can detect a missing or late check-in; an independent result check can catch a false-green run. A nightly backup, for example, should be checked for presence, freshness, and, when practical, restore validity.

Server cron, external scheduling, or monitoring?

Keep server cron when you control the host and the task must run locally. Add a heartbeat after confirmed completion if you need missing-run alerts. Use external scheduling when an application can safely expose a protected HTTPS endpoint and you want the schedule managed outside its server. Use both when a failed run matters enough to warrant independent evidence.

CronClaw can call your application’s signed HTTPS endpoint on a schedule, or watch an existing cron job through a private heartbeat. It can also check a JSON result or a separate read-only proof endpoint, record incidents, and produce reports for client workflows. It does not run arbitrary shell commands inside your server or require you to share hosting credentials.

See the scheduler versus heartbeat comparison, the business workflows CronClaw supports, and an illustrative outcome report.