Best practices

A few habits get the most out of CronWarden.

Report a value, not just a heartbeat

The single biggest upgrade over plain heartbeat monitoring is sending the number each run produced and setting a rule on it. A backup that reports its size, a sync that reports its row count — with a floor set, you find out when a job "succeeds" but does nothing. See Reporting a value.

Bracket long jobs with start and success

For anything that runs more than a few seconds, check in at /start and again on success. You get duration tracking and detection of runs that begin and stall, at the cost of one extra line. See Run duration.

Fail loudly

Have your script call /fail when it knows it failed, so you're alerted the moment it happens instead of waiting for the next missed check-in.

Set grace to match reality

Pick a grace period that covers normal jitter but no more. Too tight and you get false alarms; too loose and a real outage sits unnoticed. Start from the value CronWarden suggests and adjust once you've watched a job for a while. See Grace periods & states.

Split warnings from criticals

Point a chat channel at everything and your pager at critical only. That one choice is what keeps a slow night from waking someone while still guaranteeing a real outage gets through. See Integrations.

Name and tag consistently

Clear names ("Nightly database backup", not "cron3") and consistent tags (production, billing) make the dashboard and rollup badges far more useful as the number of monitors grows.

Manage monitors as code

Once you have more than a handful of jobs, define them with the monitors API or import your crontab so your monitoring lives in version control next to the jobs it watches.