---
title: "Why a 200 OK Killed Our Certificate Root Theory"
canonical: https://dxdev.com/blog/diagnostic-ui-false-blame/
datePublished: 2026-08-27
---
Our staff panel showed a hard red "Not on Cloudflare yet" for one customer, with a note that he still needed to update his DNS. His site was already fully live and secure. Our support lead spent hours on the phone with him because our own screen was telling her he was wrong.

Right underneath that red banner, on the same screen, sat the actual DNS lookup, live and current, showing both records already pointed at us. The panel was contradicting itself and picking the wrong side.

## One flag, two questions

The cause was one function trying to answer two different questions with one yes-or-no flag. Part of our system makes a live web request to the customer's domain to confirm we're actually serving traffic there. That request can fail for reasons that have nothing to do with the customer: our probe times out, a certificate can't be validated in that moment, the connection gets refused. Whatever the reason, a failed check and "the customer's DNS is wrong" got written to the exact same true/false value. So when our own network hiccuped, the screen said the customer hadn't done his job instead of saying "we couldn't confirm this."

## The certificate theory

We went looking for a root cause and found a red herring first. Our theory was that the security certificate chain on the customer's domain used a newer root certificate our server might not trust. That kind of problem would fail every time and need a real fix.

We ran the exact same check by hand from our own server against his domain. It came back 200 OK, a clean success, and the certificate root we'd suspected was sitting right there in the server's trusted list. The theory was wrong, and it would have sent us down a day of chasing a certificate problem that didn't exist. The actual failure was a single blip, a one-off hiccup with no retry behind it, and that blip had been permanently stamped onto a customer's account as "his DNS is broken."

If you run a business on top of software you didn't write yourself, this is the part worth sitting with. A diagnostic screen that fails silently fails as an accusation. The screen has no way to say it doesn't know. It only has the options it was built with, and if nobody built in a way to say "our check didn't work," the tool will confidently blame someone. Here it blamed a paying customer, out loud, to a staff member who then spent hours defending our system to him for a mistake he hadn't made.

## Giving the check a third answer

We did add one retry. But a retry only makes the blip less likely, and the blip still lies when it happens again. So the fix was a third answer. Besides "yes, it's working" and "no, it's not," the check can now report that it could not tell.

That third state is treated completely differently on screen. A real DNS problem still shows red and still says the customer needs to fix something. But "we couldn't confirm it" now shows as our open item, and it explains that the setup often finishes on its own within a few hours, since DNS changes need time to spread across the internet anyway.

## Splitting the panel

We also split the panel so it can't contradict itself. The question "did the customer point his DNS correctly" now reads directly from the DNS record. The question "are we actually serving the site yet" is tracked and shown separately. Before, one broken probe could paint over a correct, live DNS record with a red banner nobody could explain. Now the two facts can't overwrite each other, and whoever's on the phone can read out which half is unproven.

We tested the change against seven different real situations pulled from actual accounts, including the one where a customer hasn't pointed his DNS yet. That case still shows red and still says so. The only thing that changed is the case where our system doesn't actually know.

## What the wrong theory cost us

We had a plausible, specific story for why the check failed, and it was wrong. Running the check by hand against the live server is what caught it. If we'd shipped a fix for the certificate story instead, we would have burned time patching an issue that was never there, while the panel kept blaming customers for a problem on our end.

If you own a status or diagnostic screen, check whether a failed check can show up as "couldn't tell" rather than as a fault on the customer's side. If it can't, a one-off hiccup in your own systems will be reported as the customer's mistake, and your staff will argue it with them.