Cron expressions have five fields and roughly a dozen operators, which makes them look simple enough to write by hand — right up until a job runs at the wrong time, or not at all, and nobody notices for a week.
`0 0 1 * *` runs on the 1st of every month. `0 0 * * 1` runs every Monday. They differ by one character and mean completely different things — this is the single most common copy-paste bug in cron expressions.
`0 0 1 * 1` doesn't mean "the 1st, if it's a Monday" — most cron implementations treat this as "the 1st of the month, OR any Monday," which fires far more often than intended.
Most schedulers (crontab, many cloud cron services) default to UTC or the host's system timezone, not the timezone the person writing the schedule was thinking in. A job meant to run "at 9am" can silently run at 9am UTC instead.
`*/5` in the minutes field means "every 5 minutes starting from :00" — it does not mean "5 minutes after whenever the job was created." Assuming the offset is arbitrary is a common source of confusion when comparing two `*/N` schedules that don't seem to line up.
The day-of-week field is usually 0–6, but which end is Sunday depends on the implementation — some treat 0 as Sunday, others treat 7 as Sunday (and a few accept both). If a weekly job is running on the wrong day, this is the first thing to check.
The fastest way to catch all five mistakes above is to translate the expression into a sentence before deploying it — "at minute 0 past hour 0 on day-of-month 1" reads very differently from what you intended if you meant "every Monday." That's exactly what the Cron Generator's plain-language explanation is for: build the schedule visually, and let the explanation catch the mismatch before it ships.