Identify the wrong cron schedule

About Cron TimeLock

Cron TimeLock presents two types of challenges: pick the cron expression that matches a plain-English schedule, or spot the bug in a cron that isn't behaving as intended. Every day everyone gets the same challenge so you can compare results. Topics include DOW vs DOM gotcha, timezone confusion, step values, named fields, Quartz extensions, and DST edge cases.

Why it helps

• Build intuition for the most common cron misconfigurations that cause jobs to fire at unexpected times.
• Learn the difference between POSIX 5-field cron, Quartz 6/7-field cron, and macro shortcuts like @daily.
• Use the related Cron Builder to construct your own schedules.

Runs locally in your browser. Progress is stored only in this browser.

What this challenge teaches

Identify the wrong cron schedule is a short drill for cron schedule reasoning. A job should run at a specific business time, but the expression may use the wrong field, timezone, macro, or day-of-week rule.

Example reasoning path

• Read the prompt and identify the artifact type before looking at the answer choices.
• Compare the expected target with each candidate result and eliminate options that are only formatting changes.
• Check 5-field vs 6-field syntax and whether day-of-month and day-of-week are combined as expected.

After you solve it

Open Cron Builder to apply the same skill to your own data. For a broader practice loop, return to Skill Challenges or open Workflow Gallery when the task needs multiple tools.

Challenge state stays local to this browser. Do not paste production secrets into practice prompts.

Practice notes for real projects

Use this page as a warm-up before touching real project data. Read the prompt, write down the signal you are looking for, and only then compare answer choices. That habit carries over to production debugging, where the first visible error is often a symptom rather than the root cause.

After the challenge, recreate the same pattern in the linked tool with a harmless sample. For example, replace real tokens, user identifiers, hostnames, and request bodies with safe values, then verify that the same reasoning still works. This keeps practice useful without exposing private data.

• Save time by checking the smallest artifact that reproduces the issue.
• Write one sentence explaining why the wrong answers fail; that explanation is the skill to reuse later.
• If the challenge involves security, treat decoded or inspected data as untrusted until a separate verification step confirms it.