Build cron expressions visually by selecting schedule fields, or paste an existing expression to decode it. See the next 10 execution times, a human-readable translation, and a visual heatmap showing when your job will run throughout the week.
Pro tip: Click the preset buttons to load common schedules instantly. The heatmap shows at a glance whether your schedule does what you expect.
Paste multiple cron expressions (one per line) to find scheduling conflicts.
Cron Expression Syntax Explained
A cron expression consists of five fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-6, where 0 is Sunday). The asterisk (*) means “every,” a comma separates multiple values, a hyphen defines a range, and a slash defines intervals (*/5 means “every 5”).
Common Cron Examples
0 9 * * 1-5 runs at 9 AM on weekdays. */15 * * * * runs
every 15 minutes. 0 0 1 * * runs at midnight on the first of every month.
30 8 * * 1 runs at 8:30 AM every Monday. These are the building blocks
for most scheduled tasks.
Cron in Different Environments
The 5-field cron format is used in Linux crontab, AWS CloudWatch Events, GitHub Actions, Kubernetes CronJobs, and many CI/CD platforms. Some systems like Quartz and Spring use a 6-field format that adds seconds as the first field. AWS EventBridge uses a 6-field format with years as the last field.
Common Cron Mistakes
The most common mistakes include confusing day-of-week numbering (0 vs 1 for Sunday), forgetting that both day-of-month and day-of-week can trigger independently, and not accounting for timezone differences between the server and your local time. Always verify your expression with the “Next 10 Execution Times” panel.
Cron in Containerized and Cloud Environments
Running cron inside Docker containers requires care because the standard cron daemon
does not start automatically and environment variables set by the container runtime
are not inherited by the cron process unless explicitly forwarded. Kubernetes offers
a first-class CronJob resource that schedules Pods on a cron expression,
handles retries, and respects concurrency policies such as Forbid or
Replace — though all expressions are evaluated in UTC by default unless
the cluster is configured otherwise. On AWS, EventBridge Scheduler and CloudWatch
Events both accept cron expressions, but EventBridge uses a 6-field format that
adds a year field and does not support the ? wildcard the same way
Quartz does. The most common cloud pitfall is writing an expression in local time
without accounting for UTC offsets, which causes jobs to fire at unexpected hours
after a daylight saving time transition.
Debugging and Monitoring Cron Jobs
Testing a cron job without waiting for the scheduled time is straightforward: set
the expression to run every minute (* * * * *), verify the output,
then restore the real schedule. Structured logging is essential — write a timestamped
entry at both the start and end of each run, including the exit code, so you can
quickly identify missed or overlapping executions in your log aggregator. A
dead man’s switch, sometimes called a heartbeat monitor, is a simple and
effective reliability pattern: the job pings an external URL on successful
completion, and the monitoring service alerts you if no ping arrives within a
defined window. Services like Healthchecks.io provide this out of the box. For
mission-critical jobs, also configure alerts on the inverse condition — triggering
when the same job runs twice in a window, which indicates a concurrency bug or
overlapping schedule.
Building reliable scheduled jobs often involves validating the data those jobs produce or consume. The Regex Tester is handy for crafting and testing patterns used inside cron-driven log parsers or file-matching scripts, while the JSON Formatter & Validator helps you inspect and validate the JSON configuration files and API payloads that your scheduled tasks frequently read and write.