Cron Calculator

A cron expression is a compact, text-based schedule definition used by Unix-like operating systems, cloud platforms, and virtually every modern backend framework to trigger tasks at precise times. The name comes from cron, the time-based job scheduler built into Linux and macOS. When you want a script to run every night, every Monday morning, or at 9:15 AM on the first of each month, you encode that intent in a five-field cron string.

Each field in the expression represents a unit of time, read left to right: minute, hour, day-of-month, month, and day-of-week. Wildcards, ranges, lists, and step values let you express nearly any repeating schedule with just a handful of characters. The visual builder above converts your field choices into a valid expression in real time, and also translates raw expressions into plain-English descriptions so you can confirm the schedule does exactly what you intend.

Cron expressions are not just a Linux curiosity. They power AWS EventBridge, Google Cloud Scheduler, GitHub Actions schedules, Kubernetes CronJobs, Laravel's task scheduler, Django-celery-beat, and dozens of other production-grade tools. Learning to read and write them fluently is one of the highest-leverage DevOps skills you can develop.

Five special characters dramatically expand what a single cron field can express. Understanding them unlocks the full power of the cron calculator.

• Asterisk (*) — matches every valid value in that field. * * * * * fires every single minute of every day.
• Comma (,) — creates a list of specific values. 0,30 * * * * fires at minute 0 and minute 30 of every hour — twice per hour.
• Hyphen (-) — defines an inclusive range. 9-17 in the hour field means hours 9 through 17 — the normal business day.
• Slash (/) — defines a step interval. */15 in the minute field means every 15 minutes (0, 15, 30, 45). */2 in the hour field means every two hours.
• Question mark (?) — supported by some implementations (Quartz, AWS) to mean "no specific value," useful when you specify day-of-week but not day-of-month.

These characters can be combined. 0 8-18/2 * * 1-5 fires every two hours between 8 AM and 6 PM, Monday through Friday. The cron expression builder translates your typed values through these same parsing rules to generate the description and preview the next five scheduled run times.

Certain scheduling patterns appear so often in production systems that every developer should have them memorized. The following are the most widely used cron expressions, each of which you can load directly via the preset buttons in the calculator above.

When selecting a schedule, consider server load distribution. If all your jobs run at exactly midnight (0 0 * * *), the server spike can be significant. Staggering jobs — for example 5 0 * * * and 15 0 * * * — distributes the load and reduces contention for shared resources like databases and APIs.

Classic crontab is the original Unix job scheduler, but modern infrastructure offers many alternatives. Understanding where cron excels — and where it falls short — helps you pick the right tool.

Crontab on Linux/macOS is the simplest option: edit /etc/crontab or run crontab -e and your job is scheduled. No external dependencies, no cost, no round-trips to a cloud API. It works perfectly for server-side scripts that must run on one predictable host. The downside is that there is no automatic retry on failure, no built-in alerting, and no execution history.

AWS EventBridge Scheduler supports both standard cron syntax and rate expressions (rate(5 minutes)). It can invoke Lambda functions, Step Functions, and hundreds of other AWS targets. AWS uses a slightly extended format where you must specify either day-of-month or day-of-week as ? (not both). EventBridge is the right choice when you need serverless, highly-available scheduling without managing any infrastructure.

Kubernetes CronJobs use standard five-field cron syntax to spin up pods on a schedule. They are ideal for containerized batch workloads that must scale with the cluster and benefit from Kubernetes restartPolicy and resource limits.

GitHub Actions schedules use the same five-field syntax in the on.schedule block, letting you trigger CI/CD pipelines on a recurring basis — useful for nightly builds, dependency audits, or automated releases.

For complex workflows with dependencies between steps, tools like Apache Airflow, Prefect, or Dagster extend cron concepts with DAG-based orchestration, retries, SLAs, and observability. Start with cron for simple use cases and graduate to these platforms as complexity grows.

Even a syntactically correct cron expression can produce unexpected behavior if you overlook a few key operational concerns. Follow these best practices to keep your scheduled jobs reliable.

Always specify the timezone explicitly. The system cron daemon runs in the server's local timezone, which might be UTC, Eastern Time, or something else entirely. Cloud schedulers like AWS EventBridge and Google Cloud Scheduler let you specify a timezone when creating the rule. If your crontab file does not support a CRON_TZ variable, wrap your command in a timezone-aware shell one-liner: TZ=America/New_York date.

Redirect output to a log file. By default, cron mails command output to the local user, which often goes unread. Add >> /var/log/myjob.log 2>&1 to the end of each command to capture both stdout and stderr in a persistent log file you can review after failures.

Use absolute paths. The cron daemon runs in a minimal environment with a restricted PATH. A script that works interactively may silently fail under cron if it references commands like node, python3, or aws without their full paths. Always write /usr/bin/node or /usr/local/bin/python3 in your cron commands.

Test expressions before deploying. Use this cron calculator to confirm the next five run times match your intent before editing production crontab files. A simple off-by-one in the hour field can turn a daily job into something that never fires — or fires 24 times a day.

Protect against overlapping runs. Long-running jobs may still be executing when the next scheduled run starts. Use a lock mechanism such as flock on Linux to prevent concurrent execution: flock -n /tmp/myjob.lock /path/to/script.sh.