The question mark is a Quartz and AWS EventBridge operator meaning "no specific value." It's used in the day-of-month and day-of-week fields when you want to specify one but not the other. Standard Unix cron doesn't have this problem because it allows both fields to be set simultaneously (though the behaviour is platform-dependent). AWS EventBridge requires exactly one of them to be ?; using * in both is an error.
Both 0 and 7 mean Sunday in standard Unix cron. Most Unix cron implementations accept both. Quartz uses 1 for Sunday and 7 for Saturday (1-indexed). AWS EventBridge also uses 1 for Sunday. If you're writing for multiple systems, check which convention applies — the tool shows which format it detected and which convention it used.
Almost always a timezone issue. Cron jobs run in the server's local time by default. If your server is in UTC and you wrote an expression for 9 AM thinking it would fire at 9 AM in your local timezone, it fires at 9 AM UTC instead. AWS EventBridge always uses UTC. GitHub Actions uses UTC. Most Linux servers default to UTC. If you need a specific local time, either set the server timezone or convert your target time to UTC before writing the expression.
*/5 means "every 5th unit." In the minute field it means every 5 minutes (:00, :05, :10, :15...). In the hour field it means every 5 hours (0:00, 5:00, 10:00...). The * sets the range (the full valid range for that field) and /5 is the step. You can also use a range with a step: 0-30/5 in the minute field means every 5 minutes from :00 to :30.
Quartz expressions have 6–7 fields (with a seconds field at the start and an optional year field at the end). Standard Linux crontab and GitHub Actions use 5-field expressions with no seconds field. If you paste a Quartz expression into a Linux crontab, the parser will misread it — the seconds field gets parsed as the minutes field, and everything shifts. Strip the leading seconds field and trailing year field to convert Quartz to Unix format.
In standard Unix cron, there is no direct "last day of month" operator. The workaround is to run on the 28th, 29th, 30th, and 31st and check inside the script whether today is actually the last day. Quartz supports the L operator in the day-of-month field for exactly this purpose. AWS EventBridge also supports L. The tool will show you the correct syntax for the dialect you're targeting.
Not in standard Unix cron, which has a one-minute resolution. You can fake it by running two jobs — one at * * * * * (every minute) and one with a sleep 30 && prefix — but this is fragile. Quartz supports a seconds field (0/30 * * * * ? means every 30 seconds). For sub-minute scheduling on modern infrastructure, serverless functions with timer triggers or a proper job queue are more reliable than cron.