Schedule a cron job for a specific date and time

A traditional user crontab specifies minute, hour, day of month, month and day of week, followed by a command. To run at 09:30 on March 15 each year:

30 9 15 3 * /opt/jobs/report.sh

There is no year field here. This job repeats annually; it is not a one-time appointment.

Read the fields

A wildcard matches all values in its field. A range such as 9-17 is inclusive; a comma-separated list selects several values. Supporting implementations accept steps such as */10, which select values within a field rather than measuring elapsed time between runs.

Useful schedules

These are complete user-crontab lines, with comments on separate lines:

# Every March 15 at 09:30
30 9 15 3 * /opt/jobs/annual-report.sh

# Weekdays at 22:00
0 22 * * 1-5 /opt/jobs/nightly.sh

# The first of every month at midnight
0 0 1 * * /opt/jobs/monthly.sh

# The first of every month at 14:15
15 14 1 * * /opt/jobs/billing.sh

# Monday, Wednesday and Friday at 08:00
0 8 * * 1,3,5 /opt/jobs/collect.sh

Open the current user's table with crontab -e and inspect it with crontab -l. A system file such as /etc/crontab additionally requires a username before the command.

Watch the two day fields

In common Vixie-derived cron, when both day of month and day of week are restricted, either matching day can trigger the job. For example:

0 0 13 * 5 /opt/jobs/task.sh

This runs on the thirteenth or on Friday, not only on Friday the thirteenth. Other scheduling libraries have different semantics. To require both conditions with system cron, use one restriction in the schedule and a tested calendar guard in the script.

Use at for a one-time job

On a host with at installed and its daemon running, a simple one-time job can be submitted as:

printf '%s\n' '/opt/jobs/report.sh' | at 15:00 tomorrow
atq

Review the time and job identifier shown by at. Its parsing, environment and access policy depend on the installed implementation. Use the appropriate removal command, commonly atrm job_number, if the queued job is wrong.

Do not use an annual cron entry for one-time work and rely on remembering to remove it afterward. A suitably configured one-time systemd calendar timer is another option on systems that support it.

Verify timezone and execution

Cron commonly uses the daemon's local timezone. Cronie supports CRON_TZ; not every distribution's cron does. A job's TZ variable does not universally change the daemon's scheduling timezone. Confirm the target implementation, clock settings and daylight saving behavior.

Validate the intended next trigger, account and command. Keep application output and a completion result; successful schedule installation does not verify execution or the business outcome.

Common questions

Can I specify seconds? Traditional five-field system cron cannot. Use a scheduler supporting the needed timing semantics.

What if the host is off at the scheduled time? Ordinary cron usually misses that execution. Choose a catch-up mechanism deliberately if it matters.

Does setting a date prevent repetition? No. Without a year field or external guard, matching month/day entries recur in later years.

References

• Debian crontab syntax
• Debian cron daemon behavior