Free and Painless Cron Job Monitoring via CronMonit

John — Sat, 30 Nov 2019 15:18:56 +0000

If you ever lost data, money or customers because of a failing cron job that went unnoticed, you’ll know how important it is to monitor cron jobs.

There are a lot of different ways to monitor a cron job. Here are a couple of examples:

Instructing cron to always send all output and errors via email: https://stackoverflow.com/questions/19451680/how-to-save-cronjob-error-to-file-and-email-it
Instructing cron to only send an email when an error happens: https://stackoverflow.com/questions/19451680/how-to-save-cronjob-error-to-file-and-email-it

Solution #1 above is very noisy and will bombard your email address with lots of emails especially if you have a lot of cron jobs and they frequently run. The good thing about it is you’ll know if your cron jobs actually ran or an error happened. But this is only useful if you always and immediately check the sent emails.

Solution #2 above is better but it won’t notify you on some scenarios like cron is not running at all or if the server is down for some reason.

Another downside by using the solutions above is you’ll need to make sure that your server is able to send emails and make sure the emails doesn’t get marked as spam:

https://serverfault.com/questions/48428/how-to-send-emails-and-avoid-them-being-classified-as-spam

Plus other things that you need to worry about that I probably failed to mention here. These are all good if you love to DIY but if you want a more convenient way to monitor cron jobs, an alternative and better way is to use a cron job monitoring tool like CronMonit.

Setting up a cron job to be monitored via CronMonit only takes less than 5 minutes. You just have to create a check using CronMonit’s dashboard and configure your cron job to ping the check once it is done running by sending an HTTP request to the given ping URL.

E.g,

If your cron job is:

* * * * * script.sh

..it will become:

* * * * * script.sh && curl -fsS --retry 3 https://cronmonit.app/ping-check/91b5a171-6721-4657-b05e-35f5dde5dc0f > /dev/null

Once your cron job pings the check for the first time, CronMonit will start monitoring your cron job. If ever your cron job fails (e.g, an error happens or the cron job doesn’t run at all), you’ll get notified via email.

And by using CronMonit, if cron is not running at all or if the server is down, you’ll still get notified that there’s a problem with your cron job!

You’ll also get a simple dashboard for viewing monitored cron jobs where you can easily see which jobs are up or down:

It is really useful especially if you have a lot of cron jobs. You’ll also be able to view logs of pings and status changes which provides some useful insights about your cron jobs:

Checks can be organized by projects too:

We're currently using it on a project that uses lots of cron jobs.

Signup and start monitoring your cron jobs for free: https://cronmonit.app

Deploying a Rails App With No Downtime and No Hanging Requests

John — Sat, 30 Nov 2019 14:58:46 +0000

While working on CronMonit, I needed a way to be able to do deployments with zero-downtime and zero hanging requests.

CronMonit is a cron monitoring tool and it is able to monitor cron jobs by receiving pings (HTTP requests). A service like this can't have many downtimes or hanging requests because even just missing a few pings will cause issues for its users. Like a "cron job is down" email notification being sent even if the cron job is not really down. And because I do deployments frequently, having a way to do deployments with zero downtime and zero hanging requests is crucial.

This is the current tech stack of CronMonit:

Rails 6
Puma
Nginx
PostgreSQL

All of them are running on a single $5 DigitalOcean droplet (Ubuntu 18.04 LTS).

Luckily, it is very easy to a deployment with no downtime and no hanging requests on a rails app using puma web server. Puma has a feature called "phased restart" which kills puma workers one-by-one.

To use it, just spawn up at least 2 puma workers.

E.g,

RAILS_ENV=production bundle exec puma -w 2

Then when you need to restart puma, use the phased restart feature:

bundle exec pumactl phased-restart

Here's an example scenario that explains the process:

Do code changes on your local development environment
Commit or merge the changes to master branch
Push the changes on master branch to your central git repository (e.g, Github)
SSH into your server
cd into the directory of the git repository on your server
Pull updates from master branch (e.g, git pull origin master)
Then restart puma using phased restart

That's it!

If you're using cron jobs or scheduled tasks, you can monitor them using CronMonit for free: https://cronmonit.app/

Here's a blog post on how it works:

https://dev.to/john200ok/free-and-painless-cron-job-monitoring-via-cronmonit-8n9

DEV Community: John

Free and Painless Cron Job Monitoring via CronMonit

Deploying a Rails App With No Downtime and No Hanging Requests