Cron Expression Cheat Sheet: Syntax, Patterns, and Debugging

A cron expression is the five-field schedule that tells a Linux server when to run a command. Once you can read the five fields, you can write any schedule from "every 15 minutes" to "9 a.m. on weekdays". This cheat sheet covers the syntax, the patterns people use most, the rules that apply on Domain India shared hosting, and a checklist for jobs that silently refuse to run.

1. The five fields

 ┌──────────── minute        (0-59)
 │ ┌────────── hour          (0-23)
 │ │ ┌──────── day of month  (1-31)
 │ │ │ ┌────── month         (1-12 or JAN-DEC)
 │ │ │ │ ┌──── day of week   (0-7, where 0 and 7 are Sunday, or SUN-SAT)
 │ │ │ │ │
 * * * * *  command-to-run

Every field accepts the same building blocks:

2. Three rules that trip people up

• Steps restart every hour, day or month. */5 in the minute field means minutes 0, 5, 10 … 55, then 0 again. 0 */2 * * * means minute 0 of every second hour, not every 2 minutes.
• Day of month and day of week combine with OR. If both fields are restricted, the job runs when either matches. 0 9 1 * 1 runs on the 1st of the month and on every Monday, not only on Mondays that fall on the 1st.
• L, W, # and seconds fields are not standard cron. They belong to schedulers such as Quartz. Linux cron rejects them. "Last day of the month" needs a small check in the command instead (see section 4).

To double-check an expression, paste it into a cron explainer such as crontab.guru, which shows the next run times in plain English.

3. The everyday cheat sheet

Many cron versions also accept shortcuts: @hourly, @daily, @weekly, @monthly and @yearly (the same as 0 * * * *, 0 0 * * *, 0 0 * * 0, 0 0 1 * * and 0 0 1 1 *), plus @reboot, which runs once when the server starts. On shared hosting, write the five fields in full; @reboot only makes sense on a server you control.

4. Cron on Domain India shared hosting

We checked our cPanel and DirectAdmin shared servers in September 2026. Three rules apply to every account.

• Time zone: the servers run on Indian Standard Time, so 30 2 * * * means 2:30 a.m. IST. India does not use daylight saving time, so jobs never skip or repeat an hour.
• Where to add jobs: in cPanel, open Cron Jobs in the Advanced section; in DirectAdmin, open Cron Jobs from the advanced tools. You do not need SSH. For Webuzo, ask support for the right command paths before you schedule a PHP script.
• Same account, same limits: cron jobs run as your hosting user, inside your account's CPU and memory limits, and PHP's disabled functions apply to them too. See PHP disabled functions on shared hosting.

The full walk-throughs are in how to set up a cron job for cPanel and setting up cron jobs in DirectAdmin.

Last day of the month. Standard cron has no "last day" field, so run the job on days 28 to 31 and let the command check whether tomorrow is the 1st:

0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /bin/bash /home/USERNAME/scripts/month-end.sh

5. Real-world examples

Run a PHP script (cPanel). Name the PHP version and use full paths:

*/15 * * * * /usr/local/bin/ea-php83 /home/USERNAME/public_html/cron.php >/dev/null 2>&1

On DirectAdmin, the PHP builds are at paths such as /usr/local/php83/bin/php.

WordPress. Add define( 'DISABLE_WP_CRON', true ); to wp-config.php, then run WordPress's scheduler every 15 minutes:

*/15 * * * * cd /home/USERNAME/public_html && /usr/local/bin/ea-php83 wp-cron.php >/dev/null 2>&1

Laravel. Laravel asks for schedule:run every minute. On our shared servers that entry runs every 4 minutes, so write */4 yourself and check which of your tasks still run as intended; cron job commands explains exactly which Laravel frequencies survive.

*/4 * * * * cd /home/USERNAME/laravel-app && /usr/local/bin/ea-php83 artisan schedule:run >/dev/null 2>&1

Call a URL. Add a changing value to the URL. Our cPanel servers cache ordinary web responses for up to two hours, and a repeated URL can be answered from that cache without your script running:

*/15 * * * * /usr/bin/curl -s "https://example.com/cron.php?key=YOUR_KEY&t=$(date +\%s)" >/dev/null 2>&1

Clean up old logs. Delete .log files older than 30 days at 4 a.m.:

0 4 * * * find /home/USERNAME/logs -name "*.log" -mtime +30 -delete

Nightly database dump. Keep the password out of the command line in a ~/.my.cnf file with permissions 600, then:

30 2 * * * /usr/bin/mysqldump --single-transaction USERNAME_db | gzip > /home/USERNAME/backups/db-$(date +\%Y\%m\%d).sql.gz

6. When a cron job does not run

On a VPS you can also confirm that the cron service is running (systemctl status cron on Ubuntu or Debian, systemctl status crond on AlmaLinux or Rocky Linux) and read the system log. On shared hosting the cron service is run for you, and the server's cron log is not available to your account, so rely on your own log file.

7. Security, monitoring and when cron is the wrong tool

• Keep secrets out of crontab lines. Anyone who can read your crontab or see the process list sees them. Read them from a file with permissions 600.
• Monitor important jobs. Have the job call a heartbeat URL from a monitoring service, such as Healthchecks.io, at the end of each successful run, so you are alerted when it stops.
• Review your jobs now and then. Delete ones you no longer need; each run uses your account's resources.

Cron is for scheduled, short tasks. For work that must run more often than every few minutes, a queue worker that runs all the time, or jobs that depend on each other, use a long-running process on a VPS (with systemd timers or a process manager) or the App Platform.

Frequently asked questions

Ready to schedule your first job? Follow how to set up a cron job in cPanel, compare cPanel hosting plans, or open a support ticket with your cron line and the error from your log if a job will not run.