Cron uses the server's local time zone — specify explicitly
A cron expression with hour=9 runs at 9 AM in whatever time zone the server is configured to use. If your server is in UTC and you want 9 AM Eastern Time, you need to account for the UTC offset: "0 14 * * *" (9 AM EST = 14:00 UTC) or "0 13 * * *" during daylight saving time. Modern schedulers like AWS EventBridge and GitHub Actions let you specify a time zone explicitly — always use this option when available to avoid DST-related schedule drift.
The day-of-month and day-of-week conflict
When both day-of-month and day-of-week are specified (not *), most cron implementations use OR logic: the job runs when EITHER condition is met. "0 0 1 * 5" would run on the 1st of every month AND on every Friday — not on Fridays that fall on the 1st. If you want the latter (first Friday of the month), you need a different approach: run daily and check the date in your script.
February 29 is not a reliable schedule
"0 0 29 2 *" only fires on February 29 — which occurs only in leap years. If you need an annual job on February 29 dates, consider running on February 28 instead. The explainer's "next run times" feature immediately reveals this: if today is not a leap year, it will show that the next run is 4 years away.
Test with short intervals during development
When building a new scheduled task, test it with a "*/2 * * * *" (every 2 minutes) or "*/5 * * * *" (every 5 minutes) schedule first to verify it works correctly before switching to the production schedule. Far better than waiting 24 hours for a "0 0 * * *" job to run and discovering a bug.
Document your cron expressions with a comment
Add a human-readable comment next to every cron expression in configuration files: # "0 9 * * 1-5" — Run at 9 AM Mon–Fri. When someone reads your config in 6 months, they should not need the explainer tool to understand it. The plain-English output from the explainer is perfect for these comments.