Show HN: My weekend project – simple cron monitoring

by augustflanagan • 12 years ago

29 30 12 years ago

encoderer7• 12 years ago

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!

js2• 12 years ago

You were not aware of https://deadmanssnitch.com ?

thibaut_barrere2• 12 years ago

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!

[1] https://www.wisecashhq.com/blog/writing-reliable-cron-jobs

encoderer7• 12 years ago

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.

barce3• 12 years ago

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.

augustflanagan3• 12 years ago

Thanks! It's a django app that uses Mandrill for sending email, and Twilio for sending sms alerts.

0x420• 12 years ago

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.

encoderer7• 12 years ago

Looking at this -- it's a Firefox regression apparently. Thanks for the heads up!

eam• 12 years ago

I really liked the plan names especially the top plan, NSA (Monitor Everything). Got a good laugh out of it. :)

augustflanagan3• 12 years ago

hehe, thanks! these were fun to come up with!

acron02• 12 years ago

Awesome idea but the price outweighs the pain factor, for me.

__xtrimsky• 12 years ago

I agree with you. It's cool, but not 7$ / month, or 20$ /month cool.

thibaut_barrere2• 12 years ago

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.

encoderer7• 12 years ago

Well.. What would you pay? We're looking for more conversations with potential users to help us find the right price points.

barce3• 12 years ago

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.

acron02• 12 years ago

I agree with the sentiment of the other comments in that the price issue is only an issue from a single-user perspective and is fine for enterprise.

tyrionaura• 12 years ago

Good to have the "one is always free" plan, will give it a try.

spncr2• 12 years ago

I've gotta hand it to https://deadmanssnitch.com. Free referrals! :)

gmjosack• 12 years ago

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.

vijayaggarwal• 12 years ago

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.

crazyiiiiii• 12 years ago

Any chance of selling a version I can host myself? Or, even better, making it open source? Congrats on shipping tho!

encoderer7• 12 years ago

It was important for us to focus on the MVP but we've actually discussed both of those options from day one.

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!

yansuck• 12 years ago

I really doubt this is just a weekend project. I am sorry but titles like this has been getting on my nerves.

krapp• 12 years ago

Yeah.. I have a 'weekend project' that i've been working on for... almost a year now. And mostly not even weekends.

augustflanagan3• 12 years ago

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.

cheeken• 12 years ago

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.

encoderer7• 12 years ago

Great point, that's an important oversight.

Show HN: My weekend project – simple cron monitoring

Related Stories