Monitors
A monitor represents a single scheduled job you want to track. It defines what the job is, when it's expected to run, and how long it's allowed to take.
Monitor fields​
| Field | Description |
|---|---|
| Name | Human-readable label for the job, e.g. Daily Invoice Generator |
| Expected Schedule | Cron expression describing when the job runs, e.g. 0 9 * * * |
| Grace Period | Seconds after the expected run time before Crontify raises a missed-run alert. Default: 300 (5 minutes) |
| Timezone | The timezone in which the cron expression is evaluated. Default: UTC |
| Alert Channels | Which channels receive alerts for this monitor |
| Tags | Optional labels for organising monitors (e.g. production, billing) |
| Alert Rules | Optional rules that fire a silent failure alert based on job output metadata |
Monitor statuses​
| Status | Meaning |
|---|---|
active | The monitor is healthy and receiving pings as expected |
failing | A missed, hung, or failed run has been detected |
waiting | The monitor has never received a ping |
paused | The monitor is manually paused — no alerts will fire |
Grace period​
The grace period is the most important setting. It answers: how late is too late?
If your job runs at 09:00 and has a grace period of 300 seconds, Crontify will raise a missed run alert at 09:05 if no start ping has arrived.
Set this generously — a tight grace period on a variable-duration job will cause false alerts. A grace period of 2–5× your typical job startup time is a good starting point.
How missed runs are detected​
Crontify runs a detection loop every 60 seconds. For each active monitor, it checks whether the time since the last ping exceeds the grace period. If it does, a missed run is recorded and alerts fire.
Crontify does not evaluate your cron expression server-side to compute exact next-run times. It uses the time elapsed since the last ping. This means the monitor must receive at least one successful ping before missed-run detection activates.
Alert rules​
You can configure up to 5 alert rules per monitor. Rules evaluate numeric fields from the meta object attached to a success ping and fire a silent_failure alert when the condition is true.
For example, a rule of rows_processed eq 0 fires an alert when your job pings /success with meta: { rows_processed: 0 } — even though the job didn't throw an error.
See Alert Rules for the full reference.
Tags​
Tags are lowercase labels you can add to monitors for filtering and organisation. A monitor can have up to 10 tags. Tags are visible on the monitor list and detail pages.
Pausing a monitor​
Pausing is useful when you know a job won't run — during a deployment window, maintenance period, or deliberate downtime. Paused monitors receive pings normally but never fire alerts.
Unpause the monitor when the job resumes.