Hey HN! My friend augustflanagan and I both had a need for some really simple cron monitoring. A way to monitor our critical jobs without configuring Nagios first. We wanted a simple SAAS monitoring solution that we could trust to alert us right away when a job isn't running on schedule. <p>We mentioned this to a couple of friends who said they needed the same simple monitoring. Having people tell you they need something is a great motivator, so we built cronitor in a couple of weekends and are putting it out there. We'd love feedback and suggestions on how to make it better. Thanks!
Writing a fail-safe cron is an incredibly hard job as crons are infamous for failing rather silently. The cron script writer must take a very pessimist approach and handle every possibility of error. Even then, some scenarios are easy to miss. Following are some cases I have come across often:<p>1. <i>crash</i> - any runtime error that causes your script to stop execution abruptly.<p>2. <i>un-handled, non-crashing error</i> - db connection failure, remote api failure, file not found, etc. The script may continue execution, the results may not be logically correct.<p>3. <i>concurrent execution</i> - What if an instance of cron is not over by the time the next instance should start? crontab will simply start the next instance.<p>4. <i>internet connection error</i> - even the notification mechanism will fail if it depends on an active internet connection.<p>Your service is a very valuable one, and a challenging one too I believe. You can do a lot many things in cron monitoring and reporting.
One way I've solved this in the past which is a bit hacky but novel and fun was to set the MAILTO to some e-mail address like cron-error@ and use the local postfix process to map that e-mail to a command via transports. This allows us to inject cron errors into our exception tracking system and alert minimizing the amount of cron storming to our inboxes.
Neat little service! I'd be careful about &&'ing commands together (as in the timing example) should one of the pre-command curl calls fail. It would be a serious kick in the pants if the service to monitor the health of your cron jobs was (indirectly) responsible for preventing them from running.
Looks cool. The "Pick this Plan" buttons at the bottom don't appear to be working, though. I'm not sure if you're aware of that.