Mojah

Indeed, surprised me too - the majority of that is made up of "death by a thousand paper cuts", many 1 or 2 minute outages.

We’ve been seeing a surprising amount of leads come through this site, clearly the demand for a EU alternative is high.

Co-founder here, we'll be working on better ways to handle this over the coming days.

Update: our app is available again without Cloudflare, you'll be able to post updates to status pages smoothly again.

Interestingly, also noticing that websites that use Cloudflare Challenge (aka "I'm not a Robot") are also throwing exceptions with a message as "Please unblock challenges.cloudflare.com to proceed" - even though it's just responding with an HTTP/500.

Most companies prefer to fix any downtime before it's noticed, and sharing any details on a status page means admitting something went wrong.

There's plenty of status page solutions that tie in uptime monitoring with status updates, essentially providing a "if we get an alert, anyone can follow along through the status page" for near real-time updates. But, it means showing _all_ users that something went wrong, when maybe only a handful noticed it in the first place.

It's a flawed tactic to try and hide/dismiss any downtime (people will notice), but it's in our human nature to try and hide the bad things?

[1] ie https://ohdear.app/features/status-pages

Have you been able to try this with a `SELECT SQL_NO_CACHE * FROM ...` query?

If it's for local testing, you could try to cripple InnoDB as much as possible by just setting some absurdly low values, that would almost certainly mean no InnoDB caching is happening; https://gist.github.com/mattiasgeniar/87cd4a10bfcc788d81b51f...

Totally depends on the use case I suppose, we found that in our environment, we perform _a lot_ more SELECT's than we do UPDATE/DELETE/INSERT's.

And with some badly optimized SELECT's, the time MySQL had to spend on sorting results/reading from disk in an inefficient way made all our _write_ queries suffer.

By optimizing our SELECTs first, we freed up some CPU bandwidth (it seems?) that can be spent doing all the other work.

For web-application monitoring, we’ve [1] gone the approach of outside-in monitoring. There’s many approaches to monitoring and depending on your role in a team, you might care more about the individual health of each server, or the application as a whole, independent of its underlying (virtual) hardware.

For web applications for instance, we care about uptime & performance, tls certificates, dns changes, crawled broken links/mixed content & seo/lighthouse metrics.

[1] https://ohdear.app

Damnit, they found my loop-hole! https://ma.ttias.be/loophole-cookie-notices/

"Geeks don't have interests, they have passions."

I live by this.

Hey! Sorry to hijack the thread for the other, but just like the OP we've spent the last few years building Oh Dear and it does about 99% of what you're looking for. [1]

It has uptime, performance, SSL alerts and status pages. What's missing is the performance graphs on the status page, which is coming in a few months.

Simple Ops goes further than us by also measuring FCP though.

[1] https://ohdear.app/

One point I don't see made often: in order to short or long any market, you need _initial_ capital too. This whole "ask 1 BTC to get 2 BTC" requires 0 initial upfront costs from the attacker.

It's a win/win situation, they can't lose. They've invested nothing in their scam to begin with.

I hope everyone reads the post and not just the subject, which is misleading.

The tl;dr is: Microsoft will stop building the .exe's themselves, but PHP will still happily run on Windows. The community will most likely step in and build those binaries themselves.

For the common user, nothing much will likely change. They'll still be able to download the binaries straight of php.net, someone else will just have built them instead of Microsoft.

Hi Jake! Enter your website URL in here, and it'll tell you if you're affected or not: https://ohdear.app/tools/certificate

Here's a very quick way to check if you may be affected: this will check all certificates in the chain to see if they match the fingerprint of the to-be-revoked list.

https://ohdear.app/tools/certificate

Shameless plug, but I built a monitoring solution with extensive SSL checks that’ll catch & report these if they’re revoked: https://ohdear.app

Does this RFC just sherlock DNS Spy?

I understand.

Hard to say, as we don't have any insights into the client-side. But we can say that only ~2% of our clients had expiring root certificates in their chain in the last few weeks, so it's definitely a minority.

Since you don't control the clients in anyway, it might be that there are clients that haven't updated their local certificate stores in ages and don't yet trust the new root certificates.

This issue is largely cause by people still stuffing old root certificates in their certificate chains, and serving that to their users.

As a general rule of thumb:

1) You don't need to add root certificates to your certificate chain

2) You especially don't need to add expired root certificates to the chain

For additional context and the ability to check using `openssl` what certificates you should modify in your chain, I found this post useful: https://ohdear.app/blog/resolving-the-addtrust-external-ca-r...

For anyone interested in the code behind the halving, I had some fun dissecting the GetBlockSubsidy() function that takes care of halving & ending of block subsidy [1].

It continues to amaze me that I struggle to set up a 5-node database cluster without one going out-of-sync or split-braining every few weeks, yet the bitcoin network manages to keep thousands of miners in-sync. This has to be the best example of eventual consistency in a production network.

[1] https://ma.ttias.be/dissecting-code-bitcoin-halving/

Hi!

We’ve done this exact same thing and have a technical writeup here: https://ohdear.app/blog/how-we-used-caddy-and-laravels-subdo...

Tl:dr: very easy to do, Caddy takes care of 90% of the complexity.

Thanks, much appreciated!

Thanks!

Author here: definitely not a sponsorship, I’m not getting paid in any way. I _am_ however curious to see what this might do in terms of clicks, hence the parameters.

Oh I absolutely agree!

If you're a business, whether it's a SaaS or "just" a marketing website for your brick & mortar store, I think it's crucial to have back-ups. Most people think of backups as files, database dumps, previous versions, etc of their website. But the configuration data (in the form of DNS) isn't often considered.

You're tech-savvy and can restore your DNS records because you know yoru servers' IP address and your MX records, but who else could do the same?

Occasions are rare where I get to say "hey, I built a thing that might help here!" - so forgive me as I take this opportunity with both hands.

Whether this was a bug or a rare protective mechanisme, there will be times when your DNS provider makes a mistake and removes records. You mentioned in your post your DNS isn't hard to reproduce, but how certain are you that _all_ records are restored? How long do you have to fight DNS issues before it's OK?

I built DNS Spy [1] for this exact occasion. It monitors your DNS for any changes made, keeps a version of all DNS records (current & former) and allows you to restore/download a BIND9 zone file for your zone. You can easily import this into any commercial DNS provider or in your own BIND9/PowerDNS setup.

I would love to hear feedback on how DNS Spy could be improved when DNS disasters like these occur!

[1] https://dnsspy.io/

If you’re into Laravel and PHP, Freek is very open about all his code: https://freek.dev

I also blog about code and the financial side of running your own business: https://ma.ttias.be

Re: "Eliminate the broken URL risk"

This approach of monitoring a single URL is useful, especially if you can use the free version of monitoring services. It doesn't, however, go far enough.

Does your site only consist of a single page? Are there no links between pages? Or links to external resources?

There are few things as off-putting to your visitor by presenting them a link that ends in a 404 page.

Forgive the shameless plug, but this is the exact reason we built the Oh Dear [1] tool. We crawl the site, much like Google, to find those pages and present them to you so you can fix them.

It's not that expensive and it covers your _entire_ site, not just a single page that is designed to last. I hope your _entire_ site is designed to last, we like to help make that happen.

[1] https://ohdear.app/

I've been using this for a few days now on my own blog [1], but so far it isn't "catching on". That is to say, the revenue I seem to be making from a donation system like this is still many times smaller than a traditional advertising system or promotion of reflink services.

This isn't an issue with Buy Me a Coffee, I think it's a fundamental issue with how we perceive value of things we read & ingest online. It's hardly ever apparent how much time the author spent on a piece and the consumption of it might only take 2 minutes. Most people don't value online content to be valuable - after all, anyone can do it - right?

In my case, with ~10.000 pageviews/day (mostly helpdesk-style articles) I get about 1 coffee donation per day. Detract any costs by CC processor and the service itself, and what's left is about 0.70€ (that's 70 cents).

[1] https://ma.ttias.be/blog/