When you create a monitor in Tymo, you choose between two schedule types: a cron expression or an interval. Both answer "how often does this job run?" — but they express the answer differently, and the right choice depends on how your job is actually scheduled.
Cron expressions: time-anchored scheduling
A cron expression pins a job to a specific time of day, week, or month:
0 2 * * * # 2:00 AM every day 0 9 * * 1 # Every Monday at 9:00 AM 0 0 1 * * # First of each month at midnight 0 */6 * * * # Every 6 hours, on the hour
The key property: cron schedules are time-anchored. Every run is expected at a predictable absolute time. If you monitor a daily backup at 0 2 * * *, every day's backup is expected at 2:00am — not 24 hours after the previous run.
This matters for auditing. You can look at monitoring history and say "Monday's 2am backup arrived at 2:03am, within its grace period." The absolute timestamp carries meaning independent of when the previous run finished.
Cron expressions are also the native format for most job schedulers: crontab, Kubernetes CronJobs, GitHub Actions schedule: triggers, and AWS EventBridge all use cron syntax. If your scheduler uses cron, mirroring that expression in your monitor is the natural choice — the windows stay synchronized.
Interval scheduling: rolling windows
Interval scheduling says "run every N minutes, hours, or days" using a simple notation:
30m # Every 30 minutes 6h # Every 6 hours 24h # Every 24 hours 7d # Every 7 days
Interval schedules are rolling. Each expected ping is calculated from the last received ping. If a 24h job pings at 2:03am Monday, the next expected ping is 2:03am Tuesday. If it runs late on Tuesday (2:09am), the next window shifts to 2:09am Wednesday.
This is the right model when the exact clock time doesn't matter, only the frequency. A background worker that polls a queue every 5 minutes should use 5m. The precise start time is irrelevant; what matters is that it runs at least once every 5 minutes.
Decision guide
Use a cron expression when:
- The job runs on a defined cron schedule (crontab, Kubernetes CronJob, EventBridge)
- You need to verify the job ran at a specific time (compliance, SLA reporting)
- The job is time-sensitive — a report that must be ready before business hours
- You want monitoring history to align with log timestamps for easier debugging
Use an interval when:
- The job is triggered from application code on a timer, not a cron scheduler
- The exact start time varies based on queue depth or resource availability
- A delay in one run is acceptable and you don't want the window to fail-alarm
- You're monitoring a polling worker rather than a time-specific scheduled task
The mismatch footgun
A common mistake: using a 24h interval to monitor a job scheduled as 0 2 * * * in crontab. The schedules seem equivalent — both "every 24 hours" — but there's a meaningful difference.
The cron scheduler fires at exactly 2:00:00am. If the job takes 3 minutes, the ping arrives at 2:03am. With a 24h interval, the next expected ping is 2:03am the following day. But cron fires again at 2:00am — 3 minutes before the window. Tymo accepts early pings, so this specific case works. But the window drifts as job duration varies, and you lose the "expected at 2am" semantics you presumably wanted.
If the absolute time matters, use the matching cron expression in both your scheduler and your monitor. The windows stay in sync, your history has meaningful timestamps, and a job that slips to 3am is immediately distinguishable from one that ran on time.