Kubernetes error Six or seven fields
expected exactly 5 fields, found 6: [0 0 12 * * ?]
spec.schedule: Invalid value: "0 0 12 * * ?": expected exactly 5 fields, found 6: [0 0 12 * * ?]spec.schedule: Invalid value: "0 0 12 1/1 * ? *": expected exactly 5 fields, found 7: [0 0 12 1/1 * ? *]Message produced by running the expression through robfig/cron v3.0.1, the parser and version Kubernetes validates .spec.schedule with.
What it means
A CronJob’s .spec.schedule is checked with robfig/cron’s standard parser, which takes exactly five fields: minute, hour, day of month, month and day of week. Six fields nearly always means a seconds field from Quartz, Spring or Azure, or a year field from EventBridge. Seven means both.
The list in square brackets is how the parser split your expression. If it shows one long item, look for a wrapper like cron(…) around the fields.
Rejected expressions and their fixes
Each expression opens in the tester. The message under a rejected one is what robfig/cron v3.0.1 printed for it.
-
Use0 12 * * *At 12:00.
Quartz or Spring style, noon every day. Drop the seconds and use
*for the day of week. -
Use*/5 * * * *Every 5 minutes.
Every 5 minutes, written with a leading seconds field.
-
Use0 12 * * *At 12:00.
EventBridge style, with a year at the end.
-
Use0 12 * * *At 12:00.
Seven fields, the shape some online Quartz generators produce.
Questions
- Does a Kubernetes CronJob support seconds?
- No. The schedule has five fields, so the finest it goes is once a minute.
- Can I use
?in a Kubernetes schedule? - Yes. The parser treats
?like*, so0 12 * * ?is valid. It is the field count that matters here, not the?.
Other Kubernetes errors
- end of range (7) above maximum (6): 7Kubernetes: Sunday written as 7
- beginning of range (0) below minimum (1): 0Kubernetes: Day or month written as 0
- beginning of range (22) beyond end of range (2): 22-2Kubernetes: A range that wraps around
- failed to parse int from L: strconv.Atoi: parsing "L": invalid syntaxKubernetes:
L,#,WorH - cannot use TZ or CRON_TZ in schedule, use timeZone field insteadKubernetes:
TZ=orCRON_TZ=in the schedule