adrienjarthon

I am running another "hobbit software" (just discovered the term) for the past 12 years, and I 100% agree with Pēteri and everything he said in this blog post!

Thank you

Thanks for this feedback, I actually changed this because some of my clients complained of the opposite, that the link was a bit too "dim" and didn't look like the the obvious Call To Action in the email. But it's all very debatable I agree and I may change this again in the future.

I could but I don't want to, it's even more of a dark pattern and looks way too "spammish" IMO. I don't want my users to find this in their email and think that I'm trying to trick their system. Also I wouldn't be suprised if some antispam tries to detect this as a spam criteria.

100% agree, I also hate that I had to do this.

Hi, Adrien here author of this article (and of updown.io). That is true and I actually hesited to write the article for this reason, because it could make the spammer life easier. But after seing some of the legacy and nonsense in here I though it's still worth it so people at least understand what they are using.

Very nice tip, works quite naturaly in many contexts. Although familiar with HSL I've never though a 180deg turn was going to fix colors.

Quick update here: Vultr is still ignoring us, and Cloudflare said to one of my clients: "some IPv6 traffic from Vultr was being dropped by a DDoS mitigation system as we were receiving malicious traffic from Vultr. The issue has since been resolved, and updown should be reporting availability correctly now."

So this confirms what I suggested above, I suppose they choose not to respond with an HTML page here because it would generate too much traffic, and maybe it was a lower level TCP attack.

This also probably explains why Vultr doesn't want to answer me if they were "responsible" for the DDoS attack that got them blocked.

In my case (updown.io), I use a "scheduler" process (one per machine) which runs the following loop: every 5 seconds it fetches the checks that needs to execute in the next 5 seconds, ordered by time of run ascending. Then it iterates through them one by one, wait with a small sleep until the precise running time, and then push the job into a background job queue (sidekiq / redis in my case). This allows for a very precise timing of execution even if there is hundreds jobs per seconds, and a good distribution over time (instead of firing 100 jobs every seconds in spikes, it can schedule one every 10ms for example)

That's pretty much it, my customers are people who have websites and want to be the first to know when there's an issue on it so they can fix it, in which case a SaaS solution is usually better than some internal tools because it eliminates setup/maintenance, keeps working when all your infrastructure is down and monitors everything (including internet link). Some other clients monitor website they do not own when they depend on it, for example as a vendor I could monitor Amazon if I sell products on it to be aware of any issue, or if I'm a digital customer engagement platform (what my full-time job does) I can monitor services I interact with like facebook API, twitter API, etc.

It is quite cheap indeed, I try to keep a fair pricing :)

Thanks <3

Probably half of the time (~2-3h per week) is spent answering questions/requests from clients or helping them diagnose downtime. I try to improve the product to make sure my clients don't need me so that when they do I can help them properly.

Sounds great ;) let me know if you have any question.