Cron job monitoring

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:

  • The job does not start on time
  • The job runs for longer than expected
  • The job exits with a failure code

Creating your first cron job monitor

Creating a test monitor or monitoring a single cron job is easy and can be completed in just a few minutes.

  1. Click the button on your dashboard to create a new monitor. Select Cron job and paste the cron expression:
  2. Provide your server's timezone. A default timezone can be set from your Account Settings page.
  3. Optionally add notification methods across Email, SMS, Slack, Hipchat, PagerDuty, etc.
  4. Give the monitor a descriptive name like Offsite Database Backup and add optional tags or notes.
  5. After saving the monitor you'll be given a unique Ping API url. If you're just testing things out, use your browser to send a /run ping followed by a /fail ping 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.

Monitoring every job in your crontab

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.

  1. If you haven't installed CronitorCLI on your server, download and follow installation instructions. Save your API key using cronitor configure or pass it to discover as the -k argument.
  2. Run cronitor discover to 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.
  3. When satisfied with how cronitor discover has 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: ~ $

By default, 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.

Expected duration alerts

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:

  • With less data available on a new monitor we use wider grace periods and we will not send has not completed alerts until the job has completed successfully once.
  • API Users: Specify fixed runtime duration by adding a custom ran_longer_than rule along with the not_on_schedule rule.

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 /complete as it exits successfully. For more details on ping URL endpoints and where you should integrate your ping requests, see:

Troubleshooting Not on Schedule Rules

  • If for any reason your jobs do not start immediately at the scheduled time, you can provide an expanded grace period from your dashboard or using the API by setting the grace_seconds on your not_on_schedule rule.
  • If you receive unexpected alerts for a new monitor, review your ping history from the dashboard to ensure it matches your expectations. If there are missing pings, double check your integration. Verify that you are pinging the /run endpoint before your job and your /complete endpoint after. A missing or misplaced /run or /complete ping is the most common integration mistake.
  • By using the date command on your linux server or tzutil /g on windows you can verify that your server time matches the timezone set in your account settings.