Cron Job Best Practices
Whether you run one cron job or a thousand, following these reliability patterns will drastically reduce false alerts and make debugging easier when a genuine problem occurs.
01 Ping on Start and Success
Always send a /start ping at the beginning of your script, and a success ping at the very end. This accomplishes two things: it proves the scheduler triggered the job, and it allows HealthyCron to measure exact execution duration.
02 Use the Fail Endpoint in Exception Handlers
Don't let errors go silent by waiting for the grace period to expire. Inside your universal try/catch handler, immediately ping /fail. This guarantees instant alerts to your team rather than waiting for HealthyCron to assume it timed out.
catch(Exception e) { ping(".../fail"); throw e; }
03 Set Grace Periods Thoughtfully
Too short = false alarms whenever a server has high I/O temporarily. Too long = delayed alerts resulting in downtime. A solid rule of thumb is setting the grace period to 20-30% of the job's execution time or at minimum 2-3 minutes to accommodate network jitter.
04 Name Monitors Descriptively
Use names like "Daily-Invoice-Export", not "Job1". In pager-duty at 3:00am, a clear human-readable name is far more valuable than a generic ID.
05 Use Environment-Specific Projects
Your staging and production monitors should be completely segregated. Staging monitors usually shouldn't trigger PagerDuty. Keep production monitors in a "Production" Project, and staging inside "Staging".