A reliable cron job starts with more than a schedule expression. This guide explains cron syntax in plain English, provides reusable cron schedule examples, and gives you a deployment checklist for testing, monitoring, and safely automating recurring web tasks.
Overview
Cron is a scheduler commonly used on Unix-like systems to run commands at defined times. It can support routine maintenance, database exports, cache refreshes, report generation, certificate checks, queue processing, and other web operations. A cron expression describes when a command should run; the command itself determines what happens.
The traditional cron format has five time fields followed by the command:
minute hour day-of-month month day-of-week commandFor example:
30 2 * * * /usr/local/bin/backup-site.shThis means “run the command at 02:30 every day,” assuming the scheduler uses the server’s configured timezone. The five fields are:
| Field | Allowed values | Useful symbols |
|---|---|---|
| Minute | 0–59 | *, ,, -, / |
| Hour | 0–23 | *, ,, -, / |
| Day of month | 1–31 | *, ,, -, / |
| Month | 1–12 | *, names on some implementations |
| Day of week | 0–7 | *, names on some implementations |
An asterisk means “every valid value.” A comma lists values, a hyphen defines a range, and a slash defines an interval. For example, 0,30 means at minutes zero and thirty, 1-5 means values one through five, and */15 means every fifteen units within the field.
Because cron implementations differ, treat this as the classic five-field syntax rather than a universal rule. Some platforms add a seconds field, special shortcuts, a different timezone setting, or a hosting-specific interface. Confirm the scheduler’s accepted format before deploying an expression.
Checklist by scenario
Every few minutes
*/5 * * * * /path/to/check-queue.shUse an interval when a task should run repeatedly throughout the day. Verify that the command usually finishes before the next scheduled start. If it can overlap, add a lock or another concurrency control so two instances do not process the same work.
Once per day
15 1 * * * /path/to/generate-daily-report.shThis runs daily at 01:15 in the scheduler’s timezone. A quiet period is often preferable for resource-heavy work, but choose the time based on traffic, backups, imports, and downstream dependencies rather than assuming that overnight is always safe.
On selected weekdays
0 8 * * 1-5 /path/to/send-workday-summary.shThis runs at 08:00 on the selected weekday values. Check how the target implementation numbers Sunday and whether it accepts names such as MON-FRI. Numeric values are usually easier to move between systems, but the scheduler’s documentation remains the final reference.
Weekly maintenance
45 3 * * 0 /path/to/maintenance.shUse a weekly schedule for tasks such as cleanup or index maintenance when daily execution is unnecessary. Confirm that the job does not compete with a weekly backup or deployment window.
Monthly processing
0 4 1 * * /path/to/monthly-close.shThis runs on the first day of each month at 04:00. If you need the last day of a month, do not assume that a value such as day 31 will behave as a “last day” shortcut. Month lengths vary, and support for special last-day syntax is implementation-specific. Use a wrapper script that checks the date when portability matters.
Using lists and ranges together
0 9,13,17 * * 1-5 /path/to/sync.shThis expression runs at 09:00, 13:00, and 17:00 on the selected weekdays. It is useful when a workflow needs several predictable processing windows without running continuously.
Before adding a job to cloud hosting
- Write the schedule in plain English first: “at 02:30 every day in the server timezone.”
- Identify the exact executable, script, working directory, and user that should run it.
- Use absolute paths for commands and files wherever practical.
- Test the command manually as the same user that will run the cron job.
- Capture standard output and errors in a known log location.
- Define what should happen if the job fails or runs longer than expected.
- Record the expression and its purpose so another administrator can audit it later.
If the task is part of a wider backup plan, align the schedule with retention and restore testing. The website backup and disaster recovery plan provides a useful companion checklist. For resource-heavy jobs, also review cloud hosting resource planning before increasing frequency.
What to double-check
Timezone and daylight-saving changes
Cron usually follows a configured system, container, account, or platform timezone. That timezone may not be the one shown on your laptop or in your application. Document it explicitly and test schedules around daylight-saving transitions if the job must run at a specific local time. A schedule intended for elapsed intervals may be better handled by a system designed for interval-based execution rather than a wall-clock cron rule.
Day-of-month and day-of-week behavior
Classic cron implementations can treat the day-of-month and day-of-week fields differently when both contain restrictions. In many implementations, a job runs when either restricted field matches, rather than requiring both to match. This is easy to overlook. If you need a strict condition such as “the first Monday,” use a broader schedule with a script that checks the date, or use a scheduler that explicitly supports calendar rules.
Environment variables
Cron jobs often run with a smaller environment than an interactive shell. The expected PATH, language version, virtual environment, configuration file, and credentials may be missing. Set required variables deliberately, source a controlled environment file, or call the intended interpreter by its absolute path. Never place secrets directly in a shared cron entry or a world-readable script.
Logging, alerts, and idempotency
A schedule can be syntactically valid and still fail operationally. Send output to a monitored log, define an alert for meaningful failures, and make the task safe to retry where possible. An idempotent job produces the same intended result when repeated, rather than duplicating records, sending duplicate messages, or corrupting a partial export.
Common mistakes
- Confusing five fields with six: some schedulers include seconds, while traditional cron usually does not. Count the fields supported by the target system.
- Using a relative path: a command that works in a terminal may fail because cron starts in a different working directory.
- Ignoring permissions: the cron user may not be able to read application files, write backups, access sockets, or use the required runtime.
- Scheduling overlapping runs: frequent jobs can pile up when an API call, import, or backup takes longer than expected. Add locking, timeout handling, or queue-based processing.
- Assuming a successful start means success: the scheduler may launch a process without knowing whether the task completed correctly. Check exit codes and application-level results.
- Forgetting maintenance windows: a scheduled task can collide with deployments, database migrations, backups, or provider maintenance.
- Testing only the expression: a cron expression builder or syntax checker can confirm the timing pattern, but it cannot confirm permissions, dependencies, data safety, or application behavior.
When troubleshooting, simplify the problem: run the command manually, run it as the cron user, replace the command temporarily with a timestamp written to a test file, inspect the scheduler’s logs, and then restore the production command. Change one variable at a time.
When to revisit
Review cron schedules before seasonal planning cycles, major traffic changes, billing or reporting periods, and infrastructure migrations. Recheck them whenever a workflow, runtime, domain, database, deployment process, or hosting platform changes. A migration can alter paths, users, timezones, environment variables, and log locations even when the cron expression itself remains unchanged. The cloud hosting migration checklist can help include scheduled jobs in a move plan.
At minimum, revisit each recurring job when its purpose changes and after a missed or duplicated run. Confirm the owner, expected frequency, timezone, dependencies, alert destination, retention requirements, and rollback procedure. For a final launch review, compare the job list with the broader website launch checklist.
Action checklist: write the schedule in plain English, verify the target cron variant, test the command as the correct user, use absolute paths, record the timezone, prevent unsafe overlap, capture logs, and schedule a future review. A small amount of documentation turns a fragile cron entry into an auditable part of your web operations.
