Free Cron Expression Generator

Standard Unix cron uses 5 fields (minute, hour, day, month, weekday), while Quartz cron (used in Java applications and Spring Framework) uses 6 or 7 fields by adding a seconds field at the beginning and an optional year field at the end. Quartz also introduces special characters not found in standard cron: ? (no specific value, required in either day-of-month or day-of-week), L (last day of month or week), W (nearest weekday), and # (nth weekday of the month, e.g., 6#3 means the third Friday). Quartz also numbers days of the week 1-7 (Sunday=1) instead of 0-6 (Sunday=0). This tool generates standard 5-field cron, which is compatible with crontab, GitHub Actions, Kubernetes, and most CI/CD systems. If you need Quartz format, you will need to prepend a seconds field (usually 0) and adjust the day-of-week numbering.

Yes. GitHub Actions uses standard 5-field cron syntax in the schedule trigger of workflow YAML files. Build your expression here and paste it into the cron field under "on: schedule:" in your workflow. Be aware that GitHub Actions cron schedules always run in UTC with no timezone configuration, if you need a job at 9 AM in your local timezone, you must calculate the UTC offset yourself. Also note that GitHub Actions has a minimum interval of 5 minutes and that scheduled runs may be delayed during periods of high load on GitHub infrastructure.

Yes. Kubernetes CronJobs use standard 5-field cron syntax in the spec.schedule field of the CronJob manifest. Build your expression here and paste it directly into your YAML. Since Kubernetes 1.27, CronJobs support a spec.timeZone field where you can specify a timezone like "America/New_York" or "Europe/London", this is the recommended approach instead of relying on the cluster default. Kubernetes handles daylight saving time transitions automatically: jobs scheduled during a skipped hour (spring forward) are skipped entirely, and jobs during a repeated hour (fall back) run only once.

Yes. GitLab CI pipeline schedules, Jenkins build triggers, CircleCI scheduled workflows, and most CI/CD platforms use standard 5-field cron syntax. In GitLab, you configure schedules under Build > Pipeline schedules using cron notation with timezone selection. Jenkins uses cron in its "Build periodically" trigger and adds an H symbol that distributes load by hashing the job name. The expressions generated by this tool work directly in all of these systems, just copy and paste.

AWS EventBridge uses a 6-field cron format: minute, hour, day-of-month, month, day-of-week, and year, wrapped in cron() syntax like cron(0 9 * * ? *). The key differences are the added year field, the requirement to use ? (no specific value) in either the day-of-month or day-of-week field (you cannot specify both simultaneously), and the cron() wrapper. EventBridge also supports rate() expressions like rate(5 minutes) for simple intervals. To convert an expression from this tool to EventBridge format, add a year field (* for every year), replace * with ? in one of the day fields, and wrap it in cron().

Google Cloud Scheduler uses standard unix-cron 5-field format, so expressions from this tool work directly. Cloud Scheduler also accepts named months (JAN-DEC) and named days (SUN-SAT) in addition to numbers, and treats both 0 and 7 as Sunday. Each Cloud Scheduler job has an explicit timezone setting, avoiding the UTC-only limitation of GitHub Actions. Google also offers an alternative human-readable format called App Engine cron syntax for simpler schedules.

The most common cause of cron jobs running at unexpected times is a timezone mismatch. By default, cron uses the system timezone of the server it runs on, which may differ from your local timezone. The safest practice is to set all servers and cron daemons to UTC, then calculate the UTC equivalent of your desired local time. Be especially careful with daylight saving time (DST): jobs scheduled between 1-3 AM in timezones that observe DST may be skipped (spring forward) or run twice (fall back). On Linux you can set CRON_TZ at the top of your crontab to force a specific timezone. Kubernetes CronJobs support spec.timeZone natively since v1.27. GitHub Actions is always UTC with no timezone override.

Cron and systemd timers are both Linux task schedulers, but they differ in several ways. Cron is simpler, you edit a single crontab file with one-line schedule entries. Systemd timers require two files (a .timer unit and a .service unit) but offer significant advantages: automatic logging via journald, built-in concurrency protection that prevents overlapping runs, the ability to catch up on missed jobs with Persistent=true, dependency management so tasks wait for required services, and on-demand execution with systemctl start. Cron remains the better choice for simple, portable scheduling across Unix-like systems, while systemd timers are preferred on modern Linux servers where you need monitoring, logging, and dependency management out of the box.

Start by verifying the expression itself, paste it into this tool to see the plain-English description and confirm it matches your intent. Common mistakes include confusing field order (minute comes first, not hour), using 0-indexed vs 1-indexed values incorrectly (day-of-week 0 is Sunday, month 1 is January), and forgetting that * in day-of-week and day-of-month creates an OR condition, not an AND. On a Linux server, check that your cron daemon is running with "systemctl status cron", review cron logs in /var/log/syslog or /var/log/cron, and ensure your script uses absolute paths for all binaries and files since cron runs with a minimal PATH environment variable.

Here are frequently used expressions: "* * * * *" runs every minute. "*/5 * * * *" runs every 5 minutes. "0 * * * *" runs at the top of every hour. "0 9 * * *" runs daily at 9 AM. "0 9 * * 1-5" runs at 9 AM on weekdays only. "0 0 * * 0" runs at midnight every Sunday. "0 0 1 * *" runs at midnight on the first of every month. "0 0 1 1 *" runs once a year on January 1st. "30 2 * * *" runs at 2:30 AM daily, a popular time for backups and maintenance tasks because traffic is typically lowest.

Standard 5-field cron cannot express "last day of the month" or "nth weekday of the month" directly, these require extensions found in Quartz cron (L for last, # for nth occurrence) or platform-specific features. For the last day of the month in standard cron, a common workaround is to run a script that checks the current date and exits early if it is not the last day. Some platforms like AWS EventBridge support L in the day-of-month field natively. For "second Tuesday" scheduling, Quartz uses "3#2" (day 3 = Tuesday in Quartz numbering, #2 = second occurrence), but this is not available in standard cron.