Cron expressions turn recurring website work into a predictable schedule. The challenge is choosing a pattern that runs often enough to be useful without creating duplicate requests, server spikes, or overlapping executions. This guide provides practical cron expression examples for common website tasks and explains when each schedule is a sensible choice.
If you need a hosted scheduler instead of direct server access, FreeCronJob can run URL-based tasks and keep execution history in one place.
How a standard cron expression works
A traditional five-field cron expression follows this order:
minute hour day-of-month month day-of-week
- Minute: 0 through 59
- Hour: 0 through 23
- Day of month: 1 through 31
- Month: 1 through 12
- Day of week: commonly 0 through 6, where 0 represents Sunday
An asterisk means “every allowed value.” For example, */15 * * * * means every 15 minutes. A comma creates a list, a hyphen creates a range, and a slash sets a step interval.
Cron implementations can differ, especially around day-of-week numbering, time zones, and support for seconds. Always confirm the format expected by your scheduler before activating a production task.
Useful cron expression examples
Run every five minutes
*/5 * * * *
This schedule works for lightweight health checks, queue polling, or time-sensitive API synchronization. It is only safe when the task normally finishes well within five minutes. If a run can take longer, add locking or choose a wider interval.
Run every 15 minutes
*/15 * * * *
A 15-minute interval is a practical default for cache warming, inventory checks, feed refreshes, and non-critical monitoring. It provides frequent updates without the request volume of a five-minute job.
Run every hour
0 * * * *
This expression runs at the start of every hour. It suits hourly reports, batched notifications, sitemap refreshes, and data cleanup that does not need minute-level precision. To spread server load, consider an off-minute such as 7 * * * *.
Run once per day
30 2 * * *
This task runs daily at 02:30 in the scheduler's configured time zone. Overnight schedules are often useful for backups, analytics aggregation, log rotation, or database maintenance. However, “overnight” should reflect the audience and server region, not an assumed local time.
Run on weekdays only
0 9 * * 1-5
This pattern runs at 09:00 Monday through Friday. It is useful for business-day reports, CRM synchronization, scheduled reminders, or content workflows that should pause on weekends.
Run every Monday morning
0 8 * * 1
Use this schedule for weekly summaries, maintenance reviews, editorial reminders, or usage reports. Weekly tasks should still produce a clear execution result so a missed Monday run is easy to detect.
Run on the first day of each month
15 3 1 * *
This expression runs at 03:15 on day one of every month. Typical uses include monthly billing preparation, archive creation, account summaries, or long-term statistics.
Quick reference table
| Schedule | Cron expression | Typical use |
|---|---|---|
| Every 5 minutes | */5 * * * * |
Health checks and queue polling |
| Every 15 minutes | */15 * * * * |
Cache or feed refreshes |
| Hourly | 0 * * * * |
Reports and synchronization |
| Daily at 02:30 | 30 2 * * * |
Backups and maintenance |
| Weekdays at 09:00 | 0 9 * * 1-5 |
Business workflows |
| Monday at 08:00 | 0 8 * * 1 |
Weekly summaries |
| Monthly at 03:15 | 15 3 1 * * |
Archives and account reports |
Choose an interval based on task duration
The correct expression depends on more than freshness. Measure how long a normal run takes and how it behaves when the remote service slows down. A task that sometimes needs eight minutes should not run every five minutes unless it has a reliable lock that prevents overlap.
A useful starting rule is to keep the interval comfortably longer than the slowest expected execution. Then add a timeout, an idempotency check, and a clear failure response. For business-critical jobs, review the practical controls in our guide to cron job monitoring for reliable website automation.
Avoid running every task on the hour
Many systems schedule work at 0 * * * * or midnight. That creates synchronized traffic spikes across hosting providers and third-party APIs. An off-minute schedule such as 11 * * * * often achieves the same business goal with less contention.
You can also stagger related tasks. For example, fetch new data at minute 5, rebuild cached pages at minute 15, and send a report at minute 25. This sequence makes dependencies clearer and reduces accidental concurrency.
Account for time zones and daylight saving time
A cron expression does not explain which time zone the scheduler uses. Before publishing a schedule, verify whether it follows UTC, the server's local time, or an account-level setting. Daylight saving transitions can skip or repeat a local clock time, so UTC is often easier for system-to-system automation.
If a task must run at a user's local business hour, document the chosen time zone next to the job. Do not rely on the expression alone to communicate intent.
Make recurring tasks safe to retry
Network requests can fail after the remote service has already processed them. Design important endpoints so repeating the same request does not create duplicate invoices, emails, imports, or records. A unique operation identifier, last-run marker, or database lock can make retries safe.
- Return a meaningful HTTP status code.
- Log the start time, finish time, and result.
- Set a realistic timeout.
- Prevent overlapping runs.
- Send alerts only after a useful retry policy.
- Keep destructive maintenance behind additional safeguards.
These controls are part of a broader automation workflow. See how automated website tasks save time and reduce errors for more planning ideas.
Test a cron expression before relying on it
Start with a harmless endpoint that records the request time. Confirm at least two executions, compare the observed time with the expected time zone, and check that the scheduler reports the correct HTTP response. Then move the production endpoint into place.
After launch, review the first day of logs. A technically valid cron expression can still be operationally wrong if the job runs too often, collides with another process, or exceeds its timeout.
Schedule recurring URL tasks with FreeCronJob
FreeCronJob lets you configure scheduled URL requests without editing a server crontab. You can organize recurring jobs, review execution history, and monitor response results from a web dashboard. Choose a plan that matches your required frequency on the FreeCronJob pricing page.
The best cron expression is the simplest one that meets the real freshness requirement. Begin with a conservative interval, observe actual execution time, and increase frequency only when the task is fast, safe to retry, and properly monitored.