When you create a monitor using a cron schedule like
*/15 * * * 1-5
we will alert you if your job does not run successfully, including:
Creating a test monitor or monitoring a single cron job is easy and can be completed in just a few minutes.
/runping followed by a
/failping to simulate a job that started and then exited with an error. Read the integration guide to learn more about using CronitorCLI or Curl to send pings when your job runs.
Your new monitor is created in a paused state; monitoring will not begin until the first ping is received.
If you are monitoring jobs in a crontab file, using
cronitor discover in CronitorCLI is
the easiest way to automatically create monitors for each job and keep their schedule in sync with your server.
cronitor configureor pass it to discover as the
cronitor discoverto read the user crontab and automatically create monitors for each entry using the Cronitor API. You can use default monitor names or create your own. Your crontab will not be updated until you save changes. Run discover as many times as you need to set names correctly.
cronitor discoverhas imported your crontab, and after reviewing the stdout output for accuracy, complete the integration by saving changes.
dev01: ~ $ crontab -l 0 * * * * /var/app/bin/backup-blog.sh --full * */15 * * * /var/app/email/send-welcome-email.py 0 17 * * * /var/app/email/daily-activity-report.py dev01: ~ $ dev01: ~ $ cronitor discover --auto --save 0 * * * * cronitor exec SflG83 /var/app/bin/backup-blog.sh --full * */15 * * * cronitor exec iDNpKK /var/app/email/send-welcome-email.py 0 17 * * * cronitor exec JkY0lb /var/app/email/daily-activity-report.py 50 * * * * cronitor exec sEUGqK cronitor discover --auto Success: user "ubuntu" crontab updated dev01: ~ $ dev01: ~ $
cronitor discover adds itself as an entry to each crontab file. This feature, auto-discover, is used to push schedule changes to Cronitor and alert
you to any new jobs that have been added without monitoring.
Cronitor uses past performance to alert you when your job runs for longer than expected. Our prediction algorithm grows more precise as we learn more about your job performance but will never work perfectly for every job. If it's normal for runtime to vary significantly or if you are receiving has not completed alerts earlier than you would like, you can provide a fixed runtime duration:
To send duration alerts, Cronitor must know when your job starts running and when it completes successfully. To
report these events, you should invoke your command with CronitorCLI
exec or ping your
/run endpoint as your job starts and
as it exits successfully. For more details on ping URL endpoints and where you should integrate your ping requests,
grace_secondson your not_on_schedule rule.
/runendpoint before your job and your
/completeendpoint after. A missing or misplaced
/completeping is the most common integration mistake.
datecommand on your linux server or
tzutil /gon windows you can verify that your server time matches the timezone set in your account settings.