How to read the five fields
A cron expression is five space-separated fields: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or jan–dec) and day of week (0–7 or sun–sat, where both 0 and 7 are Sunday). Each field is a value, a list (1,15), a range (9-17), a step (*/5) or * for every value.
*/5 * * * *Every five minutes. The step applies from the start of the field's range, so this fires at :00, :05, :10 and so on.30 4 * * 1-504:30 on weekdays. A single minute and hour with a day-of-week range is the most common production shape.0 0 1 * *Midnight on the first of every month. Month-end jobs are harder: there is no “last day” in standard cron.0 0 1 * monThe trap. With both day fields set, standard cron fires on the 1st and on every Monday, not only on Mondays that are the 1st.
Containers and most cloud VMs run in UTC. A job written as 0 9 * * * on a laptop in Mumbai runs at 09:00 UTC in production, which is 14:30 IST. Switch the tool to UTC to see what the server will do, and be careful with daylight-saving zones: a schedule at 02:30 local time is skipped or run twice on the days clocks change.
A schedule is not proof that the job ran
Cron tells you when a job should start. It does not tell you whether it finished, whether it exited with an error, or whether the host it lives on is even up. Jobs fail silently when a disk fills, a credential expires or a deployment forgets the crontab entirely, and nobody notices until the report is missing or the backup is stale.
The fix is a heartbeat: the job pings a URL when it completes, and a monitor raises an alert if the ping does not arrive within the expected window. SutramX's cron monitors work this way, with a grace period you set to match the schedule you just parsed.