Release Notes

Today we published the first edition of The Cronicle, our monthly(ish) newsletter where we'll cover what we're working and thinking on.

Our product/feature release notes will be primarily shared there, but will continue to update this page with links to each edition.

Status Pages are coming soon! (And we're open-sourcing them as we go.)

Over the last two years our most frequently requested feature has been to manage public/private status pages from within your Cronitor account.

We plan to offer hosted status pages as a paid product, but we also want to be able to make it easy and free to host your own. To kick that off, our friend Vahid has created an open-source status page project for Cronitor that is easily deployable on Vercel or other JAMStack platforms.

You can see a demo (using Vahid's own monitors) at status.pabla.ir.

The beta version of Cronitor for Kubernetes has arrived for the holidays!

As engineers, we’ve watched Kubernetes evolve with great interest. When we first discovered the technical documentation we jumped immediately to the CronJob resource to understand more about how Google had re-imagined this tool that is core to our business. We were impressed, and curious, and we have been interested ever since in understanding the operational challenges and building the best solution available for Kubernetes Cron Job monitoring.

What we’ve come to believe is that fundamentally, Kubernetes has delivered on the promise of cron jobs: they remain a simple tool but finally deliver key operational guarantees like declarative provisioning, automatic retries and effortless scaling. They enable far wider and more interesting use cases than traditional cron jobs, more like a serverless platform than the monolithic background jobs we often think of as cron jobs.

We are excited to release our beta version of Cronitor for Kubernetes, giving even more operational tooling to teams deploying their background jobs on Kubernetes, and giving you a complete monitoring solution in a box, including alerts, metrics and log capture from each job.

Happy Holidays,
Shane & August

Multi-environment monitoring has moved out of beta!

Being able to configure a monitor to run in multiple environments has been one of our longest standing feature requests, and we have been working towards multi-environment support for almost a year now.

Today's release includes the final piece of environments - the ability to configure and manage those environments yourself, and to decide in which environments alerts should be sent.

Pro Tip: The alert settings of environments make it easy to disable all alerts during a maintenance window or prolonged outage.

For many years the settings section of our site was a single growing HTML file. If we needed to add a new setting, it just went to the bottom of the page. After 7 years of adding settings it got pretty hard to find what you were looking for.

With this release, we've completely re-written the settings section of the site. This makes it easy to quickly add integrations, access API keys, manage your team, sign up for reports, and more.

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