Recent Updates

$monitor = $cronitor->monitor('heartbeat-monitor');

$monitor->ping(); # a basic heartbeat event

$monitor->ping(['state' => 'run', 'env' => 'staging']); # a job/process has started in a staging environment

# a job/process has completed - include metrics for cronitor to record
$monitor->ping(['state' => 'complete', 'metrics' => ['count' => 1000, 'error_count' => 17]);

monitor = Cronitor::Monitor.new('heartbeat-monitor')

monitor.ping # a basic heartbeat event

monitor.ping(state: 'run', env: 'staging') # a job/process has started in a staging environment

# a job/process has completed - include metrics for cronitor to record
monitor.ping(state: 'complete', metrics: {count: 1000, error_count: 17})

curl -X POST https://cronitor.io/api/monitors \
    -u API_KEY: \
    -d '{
            "type": "job",
            "key": "nightly-backup-job",
            "schedule": "0 0 * * *",
            "notify": ["devops-alerts"]
        }'

import cronitor
cronitor.api_key = XXX
cronitor.generate_config() # creates a local cronitor.yaml file
cronitor.apply_config() # sync the cronitor.yaml file with Cronitor

import cronitor

@cronitor.job("an-important-job")
def main():
    print("excuting an important background job")

const cron = require('cronitor')('cronitor_api_key');
const nodeCron = require('node-cron');

cron.wraps(nodeCron);

// note the first parameter is now the key that cronitor will use
// to create a new monitor the first time the function is called.
cron.schedule('SendWelcomeEmail', '*/5 * * * *', function() {
    console.log('Sending welcome email to new sign ups every five minutes.');
});

🥳 🔠 We are releasing a major update to our telemetry tracking - B.Y.O.M.K - Bring Your Own Monitor Key!

The fundamental basis of integrating with Cronitor is using a monitor's globally unique ID to send telemetry data about a job's execution via the Telemetry Events API. While conceptually simple, this can make integrating with Cronitor cumbersome because it requires first using the dashboard or API to create a monitor in order generate a new monitor ID.

Using the new Universal Ping URL you can assign your own unique (to your account) identifier for a monitor. When a new key is detected, a new monitor is created automatically.

cronitor.link/ping/your-api-key/A-Unique-Monitor/run

The above URL contains your Telemetry Events API key, and calling it would create a new monitor named "A Unique Monitor". Rules and alert preferences could then be attached from the dashboard.

🐍🐍 Cronitor is written (mostly) in Python, so we were excited to recently move the most popular Python client (and the cronitor package on PyPi) into our Github organization, and begin contributing to its development.

Today we're launching the 2.0 version of this client. The API has changed to make it easier to work with provisioning/deployment pipelines, and will be used as a model for updates to our other clients. It also comes with something we've wanted for ourselves — a dead simple way to automagically monitor any Python function.

from cronitor import ping

@ping("An Important Function")
def main():
    ...

If that's piqued your interest, take a look at our blog post about this release, or see the project README for install instructions and documentation.

⏸ ▶️ We have released an update to our core alert delivery logic. Prior to this change, once a monitor began failing, and as long as it remained in a failing state, a follow up alert would be delivered on a pre-defined interval (8 hours by default). This could (and did) result in sending alerts for years on dead monitors.

With this release monitors will be automatically pause sending alerts after 10 consecutive alerts. If/when the monitor begins receiving the expected telemetry pings again, the expected recovery notification will be delivered, and the monitor will resume sending alerts per its rules.

✉️ 📊 Rollup reporting has been one of the most asked for features this year, and after three users requested it in a two week period we decided to bump the priority and ship this quickly.

Today we're launching summary reports. These reports will...ahem...summarize...your monitor activity (failures, new monitors, etc) for a given time period. If you're interested in receiving these reports via slack/teams instead of email, please reach out.

  is now an officially supported integration. This makes it easy to quickly authorize Cronitor to send alerts to any team/channel, and to add a channel to a notification list for re-use.

📅💡 CloudWatch Events are a great way to bring cron based scheduling to an event driven systems built onto of AWS's SNS/SQS/Lambda infrastructure.

CloudWatch events present an interesting monitoring challenge though. They use a 6 digit cron expression * * * * * * instead of the standard 5 digits. This is similar to Java Cron (Quartz, Spring, etc), however unlike Java Cron where the 6th is added to the left side of the expression and means seconds, with Cloudwatch Events the 6th digit is added to the right side of the expression and signifies years.

In order to correctly monitor CloudWatch Events we've added a special monitor type that correctly parses the 6th digit as years instead of seconds. You can select it from the dashboard or use "monitor_type": "cloudwatch" when creating a monitor via the API.

🔥📉 When tuning load times there's nothing more statifying than a chart that's down and to the right!

Refactoring our approach to calculating monitor status in bulk (e.g. opening your cronitor dashboard) has improved load times by a factor of 3-5x for accounts with 50+ monitors.

❤️📄 We're grateful to all the teams out there that take the time to write great product documentation for us, and we're committed to doing the same for our users.

Our new docs landing page has been reorganized to help you quickly find the information you need.

We rewrote and redesigned our Cron Job Setup Guide and Cron Job Integration Guide to make getting started with Cronitor even easier.

🔍📟 We've made it easy to add an alerting system to your APIs! By creating assertions on the key/value pairs in the response body itself you can quickly add monitoring to any API.

We've been using it to monitor queue lengths, alert counts, and a number of other key metrics that we've written internal APIs for.

🌐 Select regions for your Website, API and Server monitoring! This feature makes it easier to prevent false alarms by deploying monitoring close to your actual users.

Website and API monitors can also now use a Response Body Does Not Contain assertion.

🔒 Monitor your private S3 buckets to ensure they stay private. Cronitor will alert you instantly if they become publicly accessible.

🔓You can also monitor the availability and health of your public S3 buckets with assertions like Item Count > 10.