Last updated: Oct 14, 2017


All monitoring done by the CronAlarm system is determined by the parameters you specify when defining your jobs. Specifically, you can define a minimum runtime, maximum runtime, and how frequently the job should execute. When CronAlarm detects something that does not comply with your settings, we'll send you alerts.

Each job you define in CronAlarm will be assigned a unique API key. This is the key you'll use when making requests to the CronAlarm API. You can read more about making API requests in the API documentation.


CronAlarm uses the concept of 'applications' to group related jobs together. Many users may have multiple cron jobs that are all related to a specific application. For example, you may support an HR application that has cron jobs that transfer payroll information to your finance department, run reports on PTO used, backup the database, and so on. You can group all these jobs under the same application in CronAlarm so you can see the overall health of these related cron jobs together.

Another benefit is when receiving error reports. You may have multiple jobs that all deal with transferring employee data. Perhaps one of these jobs is in the HR system we already talked about, and another that copies employee data for an retirement benefit system, and so on. You can have multiple jobs in CronAlarm named 'Copy Employee Data' but assigned to different applications. When you then receive an error report, the message will include not only the name of the job, but what application it is assigned to so you know where to begin looking on your end.

Most CronAlarm users find the concept of applications quite useful, but it is not required to assign your jobs to applications in this fashion. While every job needs to be assigned to an application, you can simply create a single application (the name of your organization may be a good choice) and assign all your jobs to this.

Status Codes

Every job in CronAlarm will have a status code to indicate the current status of the job.

  •  Paused - The initial status after a job is created. Jobs will remain in a 'paused' status until the first API call.
  •  Success - The job was last run on time and no errors were detected or reported.
  •  Error - Either an error was reported via the advanced API or it's execution time fell outside your defined parameters.
  •  MIA - The job did not check in with CronAlarm within the expected interval.
  •  Running - The job is currently running. This happens after CronAlarm recieves a /start API call and before an /end API call.

Check Interval

Nothing is more frustrating than finding out one of your cron jobs failed to run at the specified time. Or, worse yet, has been failing to run for quite some time without you knowing about it. When you define your job in CronAlarm you can specify how often it should run. When it doesn't check in with CronAlarm within the time you specified, we'll let you know.

After a job checks in with CronAlarm via the /start API request, CronAlarm will begin a countdown to the next time it's expected to check in based on the check interval you specify. As a result, check interval monitoring will not begin until the first time the job checks in with CronAlarm.

Runtime Parameters

You probaby have a pretty good idea how long it should take for your job to run. If the process completes too fast or takes longer than you expect, you can probably assume something has gone wrong. When you define your job in CronAlarm you can specify minimum and maximum runtimes and if the time difference between the /start and /end API requests falls outside of your defined parameters CronAlarm will send you alerts.

All runtime parameters must be entered in terms of seconds.

If you are only worried about a job taking too long, you can set the minimum runtime value to 0 and enter your maximum runtime value in seconds. If runtime is not a concern or you do not wish to be notified based on runtime, you can leave both values to "0" and no runtime monitoring will be performed by CronAlarm.


At this time you can receive alerts in 3 ways - email, webhooks, and slack notifications. We refer to these as "integrations", and you can read more about them in the integrations documentation. Alerts can be configured on the 'Alerts' tab of the Manage Job page.

To create alerts for job failures, you link your integrations to jobs. When an error is detected, CronAlarm will look for any integrations that are currently linked to the job and send out alerts on each one.

If no alert is configured for a job (no integration is linked), an email will be sent when an error is detected to the email address used to create your CronAlarm account.

Alerts will be sent on the following conditions:

  • If the runtime for the job was either too short or too long. You can specify a minimum and maximum runtime for each job and if we detect something outside of your parameters we'll let you know. Optionally, if you are not concerned about the execution time, you can leave the minimum and maximum runtime values set to 0 to disable runtime monitoring.
  • If your job doesn't check in when we think it should. You tell us how often your job should run and it it doesn't check in with CronAlarm in that interval we'll let you know. We call these alerts "MIA Alerts" (Missing In Action). Schedule monitoring will begin after the first time your job reports to CronAlarm.
  • If you send a "success=0" parameter when using the advanced API. There may be times that you want to report your own errors, and the advanced API allows you to do that.

A really nice feature of CronAlarm when it comes to jobs that exceed their maximum runtime setting is that we don't wait for the job to be finished before we alert you. As soon as a job exceeds its maximum runtime setting CronAlarm will start sending alerts - even before the /end API is called! This can save valuable time if one of your jobs is stuck and possibly hung-up for an extended period of time.

Result History

CronAlarm will keep and display up to the last 500 results of each job. In addition to the results of each check in with CronAlarm, we'll also aggregate the results and report to you the success rate, average runtime, minimum runtime, and maximum runtime.

You can also delete results from the job history. This is helpful when you may be first testing the job with CronAlarm or are troubleshooting issues and may be running the job manually.