Cron Expression Tester

When to reach for this tool

Reach for this when you need to validate when a cron schedule will actually run during setup, debugging, or an incident review. A one-off check is useful for diagnosis, but production systems need continuous monitoring once the immediate question is answered.

• Check the next several run times, not just the next one.
• Time zone and daylight-saving shifts change when a job fires.
• The expected interval drives the heartbeat grace period.

Why cron schedules surprise you

Cron expressions are compact, which makes them easy to misread. Three things trip teams up repeatedly. Time zone: cron usually runs in the server's local zone, so a "2am" job may fire at a different hour than you intend, and daylight-saving transitions can skip or repeat a run. The day-of-month and day-of-week fields: when both are set to specific values, most cron implementations treat them as an OR, not an AND, so the job runs more often than expected. And step values (like */15) can behave unexpectedly near the top of the range. Reading the next several concrete run times — not just the next one — is the reliable way to confirm the schedule does what you mean before you attach monitoring to it.

From one-off check to continuous monitor

Use the tester to confirm the next expected run times, then set a heartbeat interval with a realistic grace period so normal scheduling jitter does not raise false alarms.

• Recreate the same check in Sandglass on an interval so the next change is caught without re-running the lookup.
• Send failures to email, a Slack webhook channel, or a generic webhook owned by whoever fixes the problem.
• Track the result over time instead of treating one manual reading as the final answer.

Why a lookup is not monitoring

A schedule that looks right can still surprise you across time zones and daylight-saving changes. Verify the concrete next run times rather than trusting the expression at a glance.