Cron Expression Debugger
Explain cron expressions in both directions, predict upcoming runs, and debug scheduler rules safely in the browser.
Reverse generation
在指定星期的 15:00 执行
0 15 * * 1,3Presets
Build, parse, and explain crontab expressions in plain English
Crontab is the de-facto syntax for scheduling jobs on Unix systems, and it is also accepted by Kubernetes CronJobs, GitHub Actions schedules, AWS EventBridge, and many CI tools. The five-field syntax is concise but easy to misread: a single misplaced asterisk can turn an hourly task into a once-per-year task. This page parses an expression, describes it in plain English, and previews the next execution times so you can verify the schedule before pushing it to production.
- Type or paste a five-field crontab expression. Optionally add a sixth field for seconds if your scheduler supports it.
- Read the human-readable description to confirm the schedule matches your intent.
- Inspect the list of upcoming run times. Skipping or unexpected gaps reveal mistakes faster than the syntax alone.
- Save the verified expression in your job configuration alongside a comment that restates the human-readable form.
Cron syntax looks simple until scheduler semantics enter the room
Cron fields are short, but the operational meaning is not. Which timezone is used? Does the platform expect five fields or six? How do day-of-week and day-of-month interact? What happens around month boundaries and daylight saving transitions? Those are the questions that cause production surprises.
A cron tool page therefore benefits from explanation, not just translation. Users need help understanding execution semantics in the environment where the expression will actually run.
Reducing scheduled-task failures in production
For important jobs, generating the expression should be only the first step. The second is validating the run window against timezone, business calendar, and platform-specific scheduler behavior.
And cron alone is rarely enough for reliability. Idempotency, retry logic, alerting, dead-letter handling, and backfill strategy matter just as much. A page that explains this becomes much more useful than a syntax helper alone.
Best use cases
- Scheduling backup, cleanup, or report jobs on Linux servers.
- Writing CronJob schedules for Kubernetes workloads.
- Defining cron schedules for GitHub Actions, GitLab CI, Cloudflare Workers, or AWS EventBridge.
Common mistakes to avoid
- Different platforms interpret the schedule in different timezones. AWS EventBridge defaults to UTC; many Linux distributions default to the server timezone.
- Specifying both day-of-month and day-of-week is ambiguous and behaves differently between cron implementations.
- Very frequent schedules (every minute or even every second) can pile up if a job runs longer than the interval. Add a lock or a "skip if previous still running" guard.
Related tools
Move directly into the next step instead of leaving the site to do adjacent work elsewhere.
Unix Timestamp Converter
Convert between Unix timestamps and human-readable dates
Nginx Config Generator
Generate nginx configuration files by selecting options. Supports SSL, reverse proxy, caching, security headers, and more.
Regex Tester
Test regex patterns, inspect a token-by-token flow view, and spot likely backtracking or ReDoS risks before they hit production.
FAQ
Does cron use UTC or local time?
It depends on the platform. Server cron uses the system timezone; many cloud schedulers use UTC. Always check the docs of the scheduler you target.
How do I run a job every five minutes?
Use `*/5 * * * *`. The slash syntax means step values, so it triggers at 0, 5, 10, ..., 55 minutes past the hour.
Why do I see two formats with five and six fields?
Classic Unix cron uses five fields starting with minute. Some schedulers (Quartz, Spring, Cloudflare) add a leading seconds field, giving six.