21–30 of 31 posts
Earlier quoted context omitted.
Cool, what did you guys code this in? I'm working on a weekend project for an EventBrite competitor focused on a really niche group of users.
Thanks! It's a django app that uses Mandrill for sending email, and Twilio for sending sms alerts.
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.
Any chance of selling a version I can host myself? Or, even better, making it open source? Congrats on shipping tho!
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!
Earlier quoted context omitted.
Thanks! It's a django app that uses Mandrill for sending email, and Twilio for sending sms alerts.
And the monitoring and alerting is done with a python daemon.
I really doubt this is just a weekend project. I am sorry but titles like this has been getting on my nerves.
I really doubt this is just a weekend project. I am sorry but titles like this has been getting on my nerves.
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.