Crontab Generator

Yes. Type something like "every weekday at 9am", "every 15 minutes", "every monday at 6:30pm" or "on the 1st at midnight" into the description box and the fields are filled in for you. It understands minute and hour intervals, explicit times in 12- or 24-hour form, midnight and noon, weekdays and weekends, individual day names (including several at once), day of month, month names, and daily/weekly/monthly/yearly. It always prints back what it understood, and if it can't ground your text in a real time or interval it says so rather than guessing — an unnoticed wrong schedule is the expensive kind of mistake.

The Crontab Generator lets you build a cron expression visually — you select the schedule using dropdowns, preset buttons, and day-of-week selectors, and the tool generates the cron expression. The Cron Parser does the opposite — you paste an existing cron expression and it translates it into a human-readable description. Use the Generator when you need to create a new schedule, and the Parser when you need to understand an existing one.

Yes. GitHub Actions uses standard 5-field POSIX cron syntax, which is exactly what this tool generates. Note that GitHub Actions schedules run in UTC timezone and may have up to 15-20 minutes of delay during high-load periods. The minimum interval for GitHub Actions is every 5 minutes (*/5 * * * *).

Standard cron expressions do not include timezone information — the timezone depends on the system running the cron job. On Linux servers, set the TZ variable in crontab: TZ=America/New_York followed by your cron line. In Kubernetes CronJob, use the timeZone field (v1.25+). In GitHub Actions, all schedules run in UTC. The next execution times shown in this tool use your browser's local timezone.

Yes, but the behavior may be surprising. In standard cron, if both day-of-month and day-of-week are specified (not *), the job runs when either condition is true (OR logic), not when both are true (AND logic). For example, "0 9 15 * 1" runs at 9:00 AM on the 15th of every month AND every Monday — not just on Mondays that fall on the 15th.

The minimum interval in standard cron is every minute (* * * * *). Most systems support this, but some platforms impose higher minimums: GitHub Actions supports minimum */5 (every 5 minutes), and some shared hosting providers limit cron to every 15 or 30 minutes. For sub-minute scheduling, you need a different tool like systemd timers or a dedicated task scheduler.

Standard cron syntax does not have a "last day of month" specifier. A common workaround is to use a shell conditional: "0 0 28-31 * * [ $(date -d tomorrow +\%d) -eq 1 ] && your_command". Some extended cron implementations (like Quartz Scheduler used in Spring) support the "L" modifier for "last day", but this is not part of POSIX cron.

Three reasons, all expected. First, GitHub Actions schedules run in UTC — not your local timezone — so a job set for '9am' fires at 9am UTC, which may be the middle of your night. Second, the minimum interval is every 5 minutes (*/5); finer schedules are rejected. Third, and most surprising: scheduled workflows are NOT guaranteed to start at the exact minute. During high-load periods GitHub queues them, and delays of several minutes (occasionally 15+ minutes, or rarely a skipped run) are documented behavior, because scheduled jobs are lower priority than push/PR-triggered ones. So never rely on Actions cron for precise timing — if you need exact, frequent execution, use a dedicated scheduler. For most 'run nightly' tasks, the imprecision is harmless once you account for UTC.

Standard cron expressions carry NO timezone — the job runs in whatever timezone the system running it is set to. To pin a timezone, the method depends on the platform: on a Linux server, set TZ in the crontab (TZ=America/New_York on its own line, then your cron entries below it); in Kubernetes CronJob, use the spec.timeZone field (v1.25+); in systemd timers, the OnCalendar directive accepts a timezone. GitHub Actions is the exception — it's always UTC with no override, so you bake the offset into the expression (and remember it shifts with DST, which is itself a reason to schedule outside DST-transition hours).