50 Useful Cron Expression Examples for Linux, WordPress, Laravel and Server Automation

Why Cron Expressions Are Still the Backbone of Server Automation

If you've spent any real time managing servers, building Laravel applications, or maintaining WordPress sites, you know that manual task execution doesn't scale. Database cleanups, email queues, log rotations, cache flushes — everything eventually needs to run on its own. That's where cron expressions come in, and despite being decades old, they remain one of the most reliable tools in a developer's operational toolkit.

Cron syntax looks simple at first glance. Five fields, a command, done. But the real power — and the real confusion — lives in the combinations. A single misplaced asterisk can mean the difference between a job that runs every minute and one that runs once a year. Understanding how to write precise expressions separates developers who set-and-forget their automation from those who spend Friday nights debugging runaway processes.

This reference covers practical cron job examples across Linux environments, WordPress scheduling, and Laravel task scheduling. Before diving in, bookmark the Cron Expression Generator — it's an excellent tool for generating, visualizing, and simulating expressions in real time before you deploy anything to production.

Understanding Cron Syntax Before You Write a Single Expression

Every cron expression follows the same structure. The standard Linux crontab format uses five time fields followed by the command:

• Minute — 0 to 59
• Hour — 0 to 23 (24-hour format)
• Day of Month — 1 to 31
• Month — 1 to 12 (or JAN–DEC)
• Day of Week — 0 to 7 (both 0 and 7 represent Sunday, or SUN–SAT)

Each field accepts specific values, ranges using a hyphen (1-5), step values using a slash (*/15), and comma-separated lists (1,15,30). Special strings like @daily, @hourly, and @reboot exist for readability, but the five-field syntax gives you far more precision — which is why most production crontabs use it exclusively.

One thing that trips up developers early on: cron runs in a minimal environment. It doesn't load your shell profile, and environment variables you rely on in your terminal may not exist. Always use absolute paths in your commands and redirect output to a log file so you can debug failures when they happen.

Linux Cron Job Examples for Everyday Server Automation

Scheduling Backups and Maintenance Windows

• 0 2 * — Run a daily database backup at 2:00 AM. The canonical choice for nightly maintenance, sitting well outside peak traffic hours for most applications.
• 0 2 0 — Run a full system backup every Sunday at 2:00 AM. Combine with the daily expression above for incremental daily backups and full weekly snapshots.
• 0 1 1 — Execute a monthly archival script on the first of every month at 1:00 AM. Useful for rolling off old log files or archiving records to cold storage.
• 30 3 1-5 — Run a cleanup task at 3:30 AM on weekdays only. The 1-5 range targets Monday through Friday exclusively.
• 0 /6 — Execute a task every six hours, firing at midnight, 6 AM, noon, and 6 PM — useful for syncing external data feeds or refreshing caches.

Log Rotation, Temp Files, and Disk Health

• /15 * — Run a script every 15 minutes. The most common sub-hourly interval in production, frequently used for lightweight health checks or incremental queue processing.
• 0 0 * — Truncate or rotate application log files at midnight daily. Keeping logs from growing unbounded is one of those tasks that bites you only when you forget it.
• 0 4 0 — Clear the system temp directory every Sunday at 4:00 AM. Running weekly rather than daily avoids unnecessary I/O on busy servers.
• 0 6 * — Run a disk usage report each morning at 6:00 AM and pipe output to a log file. Gives your team an overnight snapshot before the business day begins.
• @reboot — Execute a startup script whenever the server boots. Indispensable for launching background services or running initialization checks after an unexpected restart.

Automating Deployments and Certificate Renewals

• 0 3 1 — Pull the latest code from a repository every Monday at 3:00 AM. A common pattern for staging environment refreshes before the working week starts.
• 0 0 1 /3 — Run a task on the first day of every third month. The */3 step cycles through January, April, July, and October — a useful quarterly automation trigger.
• 0 2 15 — Execute a mid-month task on the 15th at 2:00 AM. Useful for billing script runs in SaaS applications where cycles don't align to month boundaries.
• 0 0 1 — Renew SSL certificates via Certbot every Monday at midnight. Running renewal weekly ensures you never miss the window due to a failed attempt.

What Makes WordPress Cron Scheduling Fundamentally Different

WordPress ships with its own internal scheduling system called WP-Cron — and the first thing worth understanding is that it isn't a real cron job. It's a pseudo-cron that fires when someone visits your site. For low-traffic sites, scheduled tasks can fall behind by hours or never run at all during quiet periods.

The production-grade solution is to disable WP-Cron's automatic triggering and replace it with a real server-side cron job. Add define('DISABLE_WP_CRON', true); to your wp-config.php, then set up an actual crontab entry to call the WP-Cron script via WP-CLI: wp cron event run --due-now --path=/var/www/html. Using WP-CLI instead of an HTTP request is more reliable — it doesn't depend on web server availability and produces output you can capture and log.

WordPress Cron Job Examples for Common Site Automation

• /5 * — Trigger WP-Cron every five minutes via server crontab. The most widely recommended interval for busy WordPress sites — frequent enough to keep tasks current without generating excessive load.
• 0 — Run WP-Cron on the hour for lower-traffic sites with no time-sensitive background jobs.
• 0 3 * — Schedule a WooCommerce order cleanup or expired transient purge at 3:00 AM. WordPress accumulates orphaned transients aggressively — a daily purge keeps your database lean.
• 0 1 0 — Regenerate XML sitemaps every Sunday at 1:00 AM. For content-heavy sites that don't change structure daily, weekly regeneration avoids unnecessary plugin overhead.
• /30 * — Sync WooCommerce inventory with an external warehouse system every 30 minutes, balancing data freshness against API rate limits.
• 0 0 * — Run a daily WordPress database optimization routine via WP-CLI, keeping post revisions and spam comments from bloating your tables over time.
• 0 6 1 — Send a weekly digest email to subscribers every Monday at 6:00 AM. Server-side triggering ensures the job fires at the correct local time regardless of site traffic.

Laravel Task Scheduling and the Cron Expressions Behind It

Laravel's task scheduler is one of the framework's most elegant features. When you define scheduled tasks in app/Console/Kernel.php using methods like ->daily() or ->hourly(), Laravel translates those calls into cron expressions and evaluates them on every scheduler run. The entire system hinges on a single crontab entry that fires every minute:

* cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

That one line is the heartbeat. This architecture means you never touch the crontab again after initial setup — all scheduling logic lives in version-controlled PHP code, a significant operational advantage over managing raw crontab entries across multiple servers. When built-in helpers aren't precise enough, ->cron('expression') accepts any valid expression directly.

Laravel Cron Expression Examples for Application Scheduling

• * — The master scheduler entry that must exist in your server crontab. Every Laravel scheduled task depends on this firing reliably every minute.
• 0 — Equivalent to ->hourly(). Fire a task at the top of every hour for syncing external APIs or refreshing cached reports.
• 0 0 * — Equivalent to ->daily(). Run overnight jobs like pruning stale sessions, archiving old records, or dispatching daily summary reports.
• 0 8 1-5 — Send a morning briefing email at 8:00 AM on weekdays. The weekday range eliminates the need to build day-of-week logic into the command itself.
• /10 * — Process a queue worker health check every ten minutes. Useful in environments where Supervisor isn't available and you need a lightweight fallback to restart stalled workers.
• 0 2 * — Run php artisan model:prune nightly at 2:00 AM to remove soft-deleted records older than your retention policy.
• 30 23 5 — Generate a weekly analytics snapshot every Friday at 11:30 PM, ready for Monday morning review without manual intervention.
• 0 0 1 — Reset monthly usage counters or generate invoice records on the first of each month at midnight. Common in SaaS applications with subscription metering.
• /5 9-17 * 1-5 — Poll an external integration endpoint every five minutes during business hours on weekdays, avoiding unnecessary API calls overnight or on weekends.
• 0 4 0 — Run php artisan queue:flush every Sunday at 4:00 AM to clear failed jobs and keep the queue table from becoming a diagnostic nightmare.

One consideration easy to overlook in Laravel: tasks will execute on every node in a multi-server environment unless you chain ->onOneServer() onto the definition. Without it, a job scheduled at midnight fires simultaneously across all load-balanced servers — which is almost certainly not what you want for database operations or third-party API calls.

Putting It All Together: Building a Reliable Automation Stack

The difference between cron jobs that work and cron jobs that work reliably comes down to a few disciplined habits. Absolute paths in every command. Output redirected to logs you actually review. Expressions tested in a simulator before they touch a production server. Server timezone confirmed against the times your jobs are supposed to fire. These aren't advanced techniques — they're the fundamentals that separate a crontab that quietly saves you hours from one that quietly causes data loss at 3 AM on a Saturday.

Across Linux environments, WordPress deployments, and Laravel applications, the underlying cron expression syntax is the same. What changes is the layer at which you interact with it. Linux crontab gives you direct control. WordPress wraps it in a pseudo-scheduler that needs server-side reinforcement to become dependable. Laravel abstracts it elegantly into PHP code while preserving access to raw expressions when you need them. Understanding all three levels means you can move between environments without losing your footing — and debug scheduling issues at whatever layer they actually originate.

Key Takeaways

• Cron expressions follow a five-field structure — minute, hour, day of month, month, day of week — and mastering ranges, steps, and lists gives you precise control over any scheduling interval you'll encounter in production.
• WordPress WP-Cron is not a real cron system; disabling it with DISABLE_WP_CRON and replacing it with a true server-side crontab entry is essential for reliable scheduled task execution.
• Laravel's task scheduler reduces your crontab to a single entry firing every minute, shifting all scheduling logic into version-controlled PHP — but ->cron() accepts any valid expression when built-in helpers aren't precise enough.
• Always use absolute file paths, redirect output to log files, and verify expressions in a simulator before deploying — the cron execution environment does not inherit your shell's PATH or environment variables.
• Multi-server Laravel deployments require ->onOneServer() on scheduled tasks to prevent duplicate execution; a syntactically correct expression can still produce destructive behavior if the infrastructure context isn't accounted for.