21–30 of 31 posts
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.
Loved reading the article. I can really feel the authors/founder's sincerity in giving non-fluff answers.
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.
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.
I used to use Cronitor but switched to the free (as in beer and speech) https://healthchecks.io
>100 log entries per check
Do you know what that means? (On the pricing page)
I used to use Cronitor but switched to the free (as in beer and speech) https://healthchecks.io
Looks good. >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.
Earlier quoted context omitted.
Looks good. >100 log entries per check Do you know what that means? (On the pricing page)
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…
Earlier quoted context omitted.
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…
Interesting! This type of infrastructure and coding fascinates me, thanks for sharing!