Benefits
- Plain-language description in your interface language, so you can check a schedule at a glance.
- Next runs table with an explicit time zone — browser, UTC or a common IANA zone.
- Ready
OnCalendarandCronJobsnippets with an honest note about the differences.
How to use
- Enter a cron expression or pick an example such as every minute or weekdays at 9:00.
- Or set each field with the builder: every, specific values, a range or a step.
- Choose a time zone and how many upcoming runs to show.
- Copy the systemd or Kubernetes snippet, or share the link with
?expr=and?tz=.
Cron tips
Short notes that save debugging time:
Tips
- If both day of month and day of week are restricted, classic cron runs when either matches.
- Cron uses the server time zone; DST changes can skip or repeat a run, so pin the zone explicitly where you can.
- systemd
OnCalendarand KubernetestimeZoneare close to cron but not identical — verify withsystemd-analyze calendar.
What it is for
- Checking a crontab line before it goes to production.
- Moving a job from cron to a systemd timer or a Kubernetes CronJob.
- Explaining a schedule to a teammate and sharing it as a link.
FAQ
What does */5 mean?
Every 5 units of that field starting from its minimum. In the minute field it means every 5 minutes: 0, 5, 10 and so on.
Are 0 and 7 both Sunday?
Yes. In the day-of-week field 0 and 7 are Sunday. Names JAN–DEC and SUN–SAT are accepted in any letter case.
Will systemd and Kubernetes behave exactly like cron?
Not always. The snippets are a best-effort conversion; time zones, DST and missed runs differ, so test them in the target system.
Is my expression sent to a server?
No. Parsing, the description and the next runs are calculated in your browser. A shared link only carries the expression and the time zone in the URL.