Cron Expression Generator
Pick a frequency and a time, get the cron expression. Optionally wrapped in a complete Kubernetes CronJob. Every version is fed straight back into our cron explainer, so you can see what it will actually do before you use it.
schedule
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Setting both day-of-month and day-of-week
When both are restricted cron ORs them, so the job runs on both rather than on their intersection.
Instead:Leave one as *, or use two schedules.
Assuming the schedule runs in your timezone
Kubernetes CronJobs ran in the controller's timezone, usually UTC, until spec.timeZone arrived in 1.27. Most other cron runs in the host's.
Instead:Set the timezone explicitly where supported, and write UTC otherwise.
Scheduling more often than the job takes
With concurrencyPolicy Allow, which is the default, runs overlap and accumulate until something falls over.
Instead:Set Forbid, and make the interval longer than the worst-case duration.
What it will not let you do
Most of the value in a cron generator is the expressions it refuses to produce, because the broken ones look identical to the working ones until a run is missed.
You cannot build a broken one
Every combination the form offers is a valid five-field expression, and the result is run back through our cron explainer on every change. Day of month is capped at 28 because days 29 to 31 do not exist in every month, which is a schedule that silently skips five months a year.
No day-of-month and day-of-week together
The form will not produce that combination, because cron ORs the two fields rather than ANDing them and no form can make that legible. If you want the 13th only when it is a Friday, cron cannot say it: run daily and exit early.
Steps that divide evenly
A step that does not divide into the hour restarts at the top of it, so */7 minutes fires at :00, :07 through :56, then :00 again four minutes later. The generator tells you when your step does that, rather than letting you find out from a monitoring gap.
The whole CronJob, if you want it
Tick one box and the schedule comes wrapped in a complete Kubernetes CronJob with concurrencyPolicy: Forbid, resource requests, a non-root read-only security context and history limits. Those are the same defaults our Kubernetes generator uses, and the manifest is checked by our own validator before you see it.
Building one and reading one are different jobs
You read a cron expression when somebody else wrote it and you are trying to work out what it does, usually during an incident. You build one when you already know what you want and cannot remember which field comes third.
They are separate pages for that reason, and they meet in the middle: this generator hands its output to the cron explainer on every keystroke, so you always see the sentence and the next six run times next to the expression you just built.