Every 5 minutes
| Field | Value | Description |
|---|---|---|
| Minute | */5 | every 5 minutes |
| Hour | * | every |
| Day of Month | * | every |
| Month | * | every |
| Day of Week | * | every |
- 1Fri, Feb 27, 2026, 04:55 AM
- 2Fri, Feb 27, 2026, 05:00 AM
- 3Fri, Feb 27, 2026, 05:05 AM
- 4Fri, Feb 27, 2026, 05:10 AM
- 5Fri, Feb 27, 2026, 05:15 AM
What Is a Cron Expression?
A cron expression is a compact scheduling notation used across Unix, Linux, macOS, and countless cloud services to define when recurring jobs should execute. The standard five-field format — minute, hour, day of month, month, day of week — can express everything from 'every minute' to 'at 3:30 AM on the first Monday of March and September'.
Cron was introduced in Version 7 Unix in 1979 and remains the de facto standard for job scheduling. Modern implementations appear in crontab, systemd timers, Kubernetes CronJobs, AWS CloudWatch Events, GitHub Actions, and virtually every CI/CD platform.
Cron Syntax Reference
Each of the five fields accepts specific values: minute (0-59), hour (0-23), day of month (1-31), month (1-12), day of week (0-6, where 0 is Sunday). Within each field, you can use: * (wildcard — all values), a single number (e.g. 5), a range (e.g. 1-5), a list (e.g. 1,3,5), or a step (e.g. */10 for every 10th value).
These can be combined: 1-5/2 means 'every 2nd value from 1 to 5' (i.e. 1 and 3 and 5). Some implementations also support names for months (JAN-DEC) and days (SUN-SAT), but the numeric format is universal.
Cron in Different Systems
While the core syntax is consistent, different platforms have their own extensions. Linux crontab supports @yearly, @monthly, @weekly, @daily, @hourly, and @reboot shortcuts. Kubernetes CronJobs use the standard 5-field format but add timezone support. AWS EventBridge uses a 6-field rate/cron format with an optional year field.
Systemd timers on modern Linux distributions provide an alternative to cron with calendar-based syntax (OnCalendar=) and features like randomized delays and persistent timers that catch up on missed runs. However, most developers still think in cron syntax even when using these newer systems.
Scheduling Best Practices
Avoid scheduling many jobs at exactly the same time (e.g. 0 0 * * *). Stagger start times to spread load. For non-time-critical jobs, add jitter — for example, use a random minute instead of 0.
Always set up monitoring and alerting for scheduled jobs. A job that silently stops running can go unnoticed for days or weeks. Use logging, health checks, or dead man's switches (services like Healthchecks.io or Cronitor) to verify that jobs are executing on schedule and completing successfully.
Document your cron expressions with comments. The expression '15 3 1,15 * *' is not self-documenting — add a comment explaining it runs at 3:15 AM on the 1st and 15th of every month, and why that schedule was chosen.
Frequently Asked Questions
Related Tools
Explore More Tools
Find this tool useful? Buy us a coffee to keep DuskTools free and ad-light.