The Cronicle #7
Real User Monitoring is in general beta!
The Cronicle #6
Blazing fast status pages, plus everything you need to know about Python & Cron Jobs.
The Cronicle #5
You need a Status Page! And a great solution for running distributed cron jobs, better performance charts, and more.
The Cronicle #4
Never hunt for your cron logs again! Also, new Airflow and Sidekiq SDKs just released.
The Cronicle #3
Better incident communication and real-user monitoring.
The Cronicle #2
Status Pages are here!
The Cronicle #1
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 are excited to be heading into 2022 with plans to work on status pages as a major priority for January-March. With status pages you will be able to quickly:
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:
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.');
});
🥳 🔠 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
.
cronitor discover
. With this update you can easily skip a job import withctrl-c
cronitor exec
that could cause output failures and, in certain cases, even a process deadlock.Improved navigation and design of the account settings page! In fact, this is the first change to the design of the account settings page since Cronitor launched in 2014.
Over the years we managed to cram a lot of features into that page, and as a result it became harder and harder to use. All settings are now grouped under logical sections (Team, Billing, Integrations, etc), and each section is linkable via the URL.
Monitors can now ping using email! Just send an email to {MONITOR_ID}@cronitor.link
Email pings are great ways to validate that your emails are being delivered - create a monitor to alert you if it doesn't receive an email on a given schedule or within a certain time interval. It can also be a handy way to send telemetry (ping) data from servers that can't make outbound HTTP requests, but are configured to allow SMTP requests..
To call different monitor events append the event name with a +
as shown below.
d3x0c1+run@cronitor.link
d3x0c1+complete@cronitor.link
d3x0c1+fail@cronitor.link
d3x0c1+ok@cronitor.link
Java Cron Job
, Scheduled Task
, AWS Scheduled Event
and more. Telemetry Events API
has improved ping matching logic that computes durations even when job instances overlap.discover
was not saving user crontabs on RHELdiscover
will prefill monitor names when you are re-running the commandping api
/ok
endpoint to reset a monitor back to healthy status until the next scheduled run.dashboard
pause feature will automatically send an /ok
ping when your monitor is unpaused.discover
will no longer create monitors for meta cron jobs like cron.daily
or cron.monthly
dashboard
will no longer display monitors for meta cron jobs like cronitor discover
discover
will not crash when hostnames are longer than 55 charactersdiscover
now includes the cron job administration tools list
, select
and shell
discover
will no longer create monitors with duplicate names in some edge conditionsdiscover
will display an interactive prompt even when no $PS1
is setdiscover
now supports the editing of auto-generated names at the interactive promptdiscover
will prompt a user to save updated crontab if no automatic --save
flag is supplieddiscover
can now be supplied a path to a single crontab or a directory of crontabs.discover
will automatically find jobs in /etc/cron.d
when run as a root user.discover
interactive shell is cleaner and more descriptive.exec
will no longer strip newline characters from stdout and stderr.exec
will relay signals. Signals will now be ignored by the exec
process and sent directly to the subprocess. Note that in Unix-based operating systems like Linux SIGKILL cannot be caught or relayed.exec
will return stdout and stderr from subprocess as a combined stdout stream. Before this change the output was buffered until the subprocess exited.exec
will relay the exit code from the subprocess. If your subprocess returns code 127, exec
will return 127.exec
will no longer append a newline when writing stdout from the subprocess.ops.default
couldn't be deleted.discover
increase timeout to accommodate crontab files with hundreds of jobs.NotRunAt
rule type for heartbeat monitors. With this rule type you will be alerted if a ping is not sent by a certain time each day.status
textdiscover
can accept a --notification-list
argumentexec
will now set the environment variable CRONITOR_EXEC=1
so a process can know if it's being run under exec.discover
interactive mode to easily customize monitor names during crontab import.discover
will automatically find your user crontab if no file is supplied.