Release Notes

Group management finds a home in the Cronitor 2.0 UI.

Groups were one of the most requested features that we added in the Cronitor 2.0 release earlier this summer. In fact, we were so excited to get them out, we built all the UI for groups themselves, but shipped without the ability to easily create/edit groups and bulk assign monitors to them.

This release provides a simple UI to quickly create groups directly from the home screen, and add any ungrouped monitor(s) in bulk to a new or existing group.

Cronitor 2.0 has moved from beta to general availability! 🎉

The new application has been the default experience for our existing customers for the better part of the past month (thanks for all the feedback/bug reports!), but without a proper onboarding experience, new users were still being sent to the 1.0 version. We've finished rebuilding the first-time user experience, and are excited to hear your feedback!

The new onboarding flow focuses on defining the three key types of monitoring that Cronitor provides — jobs, heartbeats, and checks.

Our community driven open-source SDKs are now front and center in onboarding flow, and we will continue to invest in making these the default way to integrate with Cronitor, whatever platform you may be using.

Release notes have been sparse this year, but not for a lack of shipping code.

Over the past 5 months our team has been focussed on rebuilding our entire web application behind a feature flag. This has touched every single part of our system, introduces a ton of new features, and lays the foundation for some really cool things to come. It's such a complete overhaul that we're calling it Cronitor 2.0.

The current previous version of our web application had its first commits in 2014. It was our first time using tools like React, Bootstrap, Redux, and ES6 (as it was known at the time). While we got some things right, we got some others very wrong, and we're pretty happy to be burning it to the ground 🔥🔥🔥

As we've rebuilt Cronitor we've incorporated years of feedback into the new product. First and foremost we make it much easier to monitor the performance and execution time of your cron jobs.

Our two most frequently requested features over the past couple of years are also included in this release. You can now:

1. Run monitors in multiple environments (prod, staging, etc) removing the need to create copies of monitors or have special handling per environment.
2. Create groups of monitors (per team, geographic region, host, etc). Each group has its own URL, and soon you'll be able to define notifications and access control lists (ACLs) at the group level.

In the next few weeks we will add dedicated Incident and Log pages to make it easier to view/search the execution and alert history of all your monitors. Logging will also get a much deeper integration with our CLI, and you'll soon be able to send your full cron logs to Cronitor!

     New versions of our PHP and Ruby SDKs are now available! We are grateful to all our customers, friends, and supporters who have helped make this possible!

$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})

🤖 ❤️ Today, with love, we are launching the new version of our Monitor API to all users.

This release is a long time coming - it's the first major API overhaul in almost 5 years - and makes the process of managing your monitors' configuration much easier.

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

You can also generate a YAML representation of all of your monitors by making a GET request to https://cronitor.io/api/monitors.yaml. This is used by our SDKs to allow you to version control/deploy your monitor configuration settings.

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

☃️ 🚀 ☃️ Happy holidays and congratulations on (almost) surviving 2020! We just released new major versions of our Python and Node libraries!

Both of these libraries build upon our new Monitor API and use the Universal Ping URL to auto-provision new monitors when a new key is detected.

Our Python library was the first of our clients to support autoprovisioned monitors, and we are now standardizing each of our libraries to expose the same API.

With this release, all it takes to monitor any function in Python is:

import cronitor

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

Our Node library now has drop in support for both Node-Cron and, uh, Node Cron.

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.');
});