Downdetector and the real cost of no upstream dependencies

The below is one out of five topics from The Pulse #154. Full subscribers received the below article two weeks ago. To get articles like this in your inbox, every week, subscribe here.

Many subscribers expense The Pragmatic Engineer Newsletter to their learning and development budget. If you have such a budget, here’s an email you could send to your manager.

One amusing detail of the November 2025 Cloudflare outage is that the realtime outage and monitoring service, Downdetector, went down, revealing a key dependency on Cloudflare. At first, this looks odd; after all, Downdetector is about monitoring uptime, so why would it take on a key dependency like Cloudflare if it means this can happen?

Downdetector was built multi-region and multi-cloud, which I confirmed by talking with Senior Director of Engineering, Dhruv Arora, at Ookla, the company behind Downdetector. Multi-cloud resilience makes little sense for most products, but Downdetector was built to detect cloud provider outages, as well. And for this, they needed to be multi-cloud!

Still, Downdetector uses Cloudflare for DNS, Content Delivery (CDN), and Bot Protection. So, why would it take on this one key dependency, as opposed to hosting everything on its own servers?

A CDN has advantages that are hard to ignore, such as:

• Drastically lower bandwidth costs – assets cached on the CDN are much faster
• Faster load times because assets on a CDN are served from Edge nodes nearer users
• Protection from sudden traffic spikes, as would be common for Downdetector, especially during outages! Without a CDN, those spikes could overload their services
• DDoS protection from bad actors taking the site offline with a distributed denial of service attack
• Reduced infrastructure requirements, as Downdetector can run on fewer servers

Downdetector’s usage patterns reflect that it’s a service very heavily used by consumers whom the business doesn’t really monetize (Downdetector is free to use.) So, Downdetector could get rid of Cloudflare, but costs would surge, the site would become slower to load, and revenue wouldn’t change.

In the end, Downdetector’s dependence on Cloudflare could be a pragmatic choice based on the business model, and how removing its upstream dependency upon Cloudflare could get very expensive!

Dhruv confirmed this and sharing more about the design choices at Downdetector:

“Building redundancy at the DNS & CDN layers would require enormous overhead. This is especially true as Cloudflare’s Bot Protection is world-class, and building similar functionality would be a lot of effort. There are hyperscalers [cloud providers] that have this kind of redundancy built in. We will look into what we can do, but with a team size in the double digits, building up a core piece of infra like this is a pretty tall order: not just for us, but for any mid-sized team.

We’ve learned that there are more things that we can improve, for the future. For example, during the outage, the Cloudflare control pane was down, but their API wasn’t. So, us having more Infrastructure as Code could have helped bring back Downdetector sooner.

On our end, we also noticed that the outage wasn’t global, so we were able to shift traffic around and reduce the impact.

One more interesting detail: Cloudflare’s Bot Protection went haywire during the outage, and started to block legitimate traffic. So, our team had to turn that off temporarily”.

Thanks very much to Dhruv and the Downdetector team for sharing details.