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.
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!
There are others, like Proby (which I mentioned here [1]), yet I find that having more competitors in that space would be helpful, because not everyone has exactly the same needs. Congrats for shipping!
We gave it a shot but there were a couple things we needed that we couldn't get from DMS. Specifically, I have hourly jobs that started taking longer than an hour to run. I needed timing-based alerts for that. We also needed to be alerted in real time in a way DMS doesn't provide.
As a counter-point I will say that most of my freelancing clients are perfectly willing to pay that and more, for platforms where a cron that misbehaves has consequences.
I would suggest not to lower the prices :-)
EDIT: I prefer to pay more than $20/mo if this means that your product won't end up being stale and unmaintained.
The prices seem really reasonable and a steal if I was still in an enterprise environment. I'm not maintaining any prod servers right now, but $4.99 would be a sweet spot if I had a few hobby servers on the Internet that I was doing devops for.
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.
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:
1. crash - any runtime error that causes your script to stop execution abruptly.
2. un-handled, non-crashing error - db connection failure, remote api failure, file not found, etc. The script may continue execution, the results may not be logically correct.
3. concurrent execution - What if an instance of cron is not over by the time the next instance should start? crontab will simply start the next instance.
4. internet connection error - even the notification mechanism will fail if it depends on an active internet connection.
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.
You're right. Weekends project would be a better title.
We built an end to end proof of concept our first weekend on it, then spent another Sunday polishing it as well as a few hours here and there a couple of evenings.
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.
30 comments
[ 3.4 ms ] story [ 77.1 ms ] threadWe 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!
[1] https://www.wisecashhq.com/blog/writing-reliable-cron-jobs
I would suggest not to lower the prices :-)
EDIT: I prefer to pay more than $20/mo if this means that your product won't end up being stale and unmaintained.
1. crash - any runtime error that causes your script to stop execution abruptly.
2. un-handled, non-crashing error - db connection failure, remote api failure, file not found, etc. The script may continue execution, the results may not be logically correct.
3. concurrent execution - What if an instance of cron is not over by the time the next instance should start? crontab will simply start the next instance.
4. internet connection error - even the notification mechanism will fail if it depends on an active internet connection.
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.
There are some disadvantages to self hosting a monitoring tool. But certainly there are circumstances where self hosting is very important.
I could certainly see us releasing code for the website and monitor daemon under an OSS license at some point.
Thanks for giving it a look!
We built an end to end proof of concept our first weekend on it, then spent another Sunday polishing it as well as a few hours here and there a couple of evenings.