Re:Growing a cron job monitoring side project into a real bu...
by frakkingcylons on Monday February 20, 2017 @02:59AM
(#13685347)
I've been using Cronitor since spring of 2014 and it's been great. I initially used it to monitor the uptime of the real-time location feed from my local transit agency (so I could email them to fix it). It was pretty remarkable being able to setup monitoring in ~5 minutes with a single line of code. Now I use it for tons of daemons and cron jobs, it's pretty great to actually have them monitored (not to mention the super simple duration tracking).
Once, it appeared that I was getting false-positive alerts so I called the phone number (not really knowing what to expect) and when (Shane I think?) picked up on the first call I was just flabbergasted that someone was available almost immediately to explain my monitor's behavior. (I had conflated the /run ping with the /complete ping). I highly recommend the service based on their support and my good experience with their API.
Re:Growing a cron job monitoring side project into a real bu...
by cuu508 on Monday February 20, 2017 @04:39AM
(#13685866)
Maintainer here! For each monitored job healthchecks.io keeps a historic log of received pings. Each log entry has time, source IP and HTTP User-Agent header. These are useful to answer questions like:
* are my pings always right on time? What's the time variance?
* what IPs am I receiving pings from?
* who's pinging me -- a wget or curl utility, somebody using a browser, or some HTTP library?
The number "100" means that for each monitored job, the service will keep 100 most recent log entries, and will prune older entries.
Re:Growing a cron job monitoring side project into a real bu...
by encoderer on Sunday February 19, 2017 @01:22PM
(#13681048)
August is in Thailand where it's 1AM but I wanted to thank Courtland for having us on IndieHackers. We've learned a lot from these interviews and are happy to give back.
Re:Growing a cron job monitoring side project into a real bu...
by axelut on Sunday February 19, 2017 @01:28PM
(#13681089)
Congrats for the awesome journey! A lot of useful insights that we will use for our startup too, answering on Stack Overflow is a thing that I didn't think about till now. At this moment we are using uptimerobot for our creative-tim.com and for our demos, blog etc. We will give a try to Cronitor too. The link for "http://startupli.st/" didn't work, do you have another one?
Re:Growing a cron job monitoring side project into a real bu...
by ezekg on Sunday February 19, 2017 @06:13PM
(#13682769)
I don't exactly remember how I first came across Cronitor (I thought it was IH, but I guess not), but you guys have been a big inspiration for me as I've been attempting to bootstrap my own side project into a business.
Re:Growing a cron job monitoring side project into a real bu...
by greenleafjacob on Sunday February 19, 2017 @11:05PM
(#13684207)
Cronitor is great. A few months back I used cronitor for a use case that ended up hitting their ping endpoint at about 10-15 QPS, and they said there was some capacity constraint they were running into (not exhausting though). I would love to hear more about the architecture behind cronitor.
Re:Growing a cron job monitoring side project into a real bu...
by augustflanagan on Monday February 20, 2017 @02:16AM
(#13685116)
Thanks Jake! We'll definitely write some posts in the coming months about our architecture. We never intended to be running a high-availability service, and we have learned a lot of lessons along the way.
Re:Growing a cron job monitoring side project into a real bu...
by bartread on Sunday February 19, 2017 @10:11PM
(#13683956)
I agree. Absolutely fantastic piece and a real encouragement to the rest of us who want to live that dream. I wish you guys the best for the future: you remind me a lot of a company I used to work for called Red Gate. Keep this up and I reckon there's a good chance you'll be making hundreds of thousands a month in five years' time.
Re:Growing a cron job monitoring side project into a real bu...
by augustflanagan on Monday February 20, 2017 @02:18AM
(#13685126)
Thanks so much y'all! Sincerely appreciate the encouragement, and if there's ever anything we can do to help out/give back to such a wonderful community please don't hesitate to get in touch with us.
Re:Growing a cron job monitoring side project into a real bu...
by rdoherty on Sunday February 19, 2017 @10:31PM
(#13684053)
I'm curious, how does Cronitor actually monitor that the URLs were pinged at the correct times or at all? Part of me thinks they are using cron to check statuses?
Re:Growing a cron job monitoring side project into a real bu...
by encoderer on Sunday February 19, 2017 @10:42PM
(#13684108)
We built a python daemon that owns a shard of monitors, iterates them, reads recent history, and dispatches alerts when appropriate. The key things I thought were important when it was built were:
- stateless (needs to be able to be arbitrarily restarted at any time)
- fast (we need to be able to send alerts right when a job fails)
- simple (we will run pings thru a series of simple evaluators where test coverage is easy)
Once, it appeared that I was getting false-positive alerts so I called the phone number (not really knowing what to expect) and when (Shane I think?) picked up on the first call I was just flabbergasted that someone was available almost immediately to explain my monitor's behavior. (I had conflated the /run ping with the /complete ping). I highly recommend the service based on their support and my good experience with their API.
The service is continually improving and the customer support has been second-to-none, they have gone above and beyond to meet my needs.
"The ops team consists of a single person, so multi-hour or even multi-day outages are possible".
>100 log entries per check
Do you know what that means? (On the pricing page)
* are my pings always right on time? What's the time variance?
* what IPs am I receiving pings from?
* who's pinging me -- a wget or curl utility, somebody using a browser, or some HTTP library?
The number "100" means that for each monitored job, the service will keep 100 most recent log entries, and will prune older entries.
- stateless (needs to be able to be arbitrarily restarted at any time)
- fast (we need to be able to send alerts right when a job fails)
- simple (we will run pings thru a series of simple evaluators where test coverage is easy)