The Green 200 That Wasn't Proof

The little green check mark beside 200 on my screen looked like the end of a job. A 200 is just a website’s shorthand for “the page answered okay.” I had changed where a customer’s web address was meant to go, refreshed the page, and got that green result. The page loaded. I wrote down that the change was verified and moved on.

Then I removed one old setting that I was sure had become unnecessary. The page immediately stopped working.

That was an uncomfortable way to learn that the green 200 had not told me what I thought it told me. It had proved that something answered the request. It had not proved that the new route answered it.

The old setting was a leftover entry for that one web address. Think of it like an old forwarding label on a mailbox. The plan was to stop making a separate label for every address and use one shared route instead. That shared route was meant to be simpler and easier to keep up to date. Before removing the old label, I changed the address to point toward the shared route and checked that the page still appeared.

It did. That was the mistake.

There were two possible ways for the page to appear. The new shared route might have been doing its job. Or the old, temporary route might still have been quietly carrying the whole load. I treated a successful page load as proof of the first possibility without ruling out the second.

When I removed the old entry, the answer came fast. The page was not found. The old route had been doing all the work. The new route had not served a single request yet.

My first check did not work, and it cost a few uneasy minutes while a page that should have been available was not. That is not a dramatic amount of time on a clock. It is still enough time to feel the difference between “I have evidence” and “I saw something I wanted to believe.”

I did not want to guess at the cause. One possibility was that the service between the visitor and the website was sending the request to the wrong place. Another was that the web server was getting confused by which address it was asked for. Both were reasonable stories. Neither was a fact yet.

So I checked the two parts separately. From the public side, the page was still coming back as missing. From the new destination itself, the response was different. That gap looked important at first. It suggested that the address on the request might be steering people to different places.

I tried changing every version of the address I could think of when checking the new shared route. Every one gave the same response. None gave the missing-page result that people were seeing from the public side. That ruled out the story I had just spent time testing.

The boring answer was the right one. The change had simply not finished taking effect everywhere yet. Technical people call that propagation lag. In ordinary words, the instruction had been sent, but the service in the middle had not received and started using it yet. It was still sending visitors to the old destination.

About two to three minutes later, the new shared route took over. The page came back with a real 46KB response, not the 404 I had just seen. I checked it six times. It worked six times in a row. Only then did I have the proof I thought I had at the start.

In hindsight, the timeline is almost embarrassingly simple. I changed the route. The change was still travelling through the system. I checked too soon. The old setting made the page look healthy, so I called the new setup finished. I removed the old setting. The old path disappeared before the new one had taken over. The page failed until the change caught up.

The part that stays with me is not the delay. A delay of a few minutes is something I can plan around next time. The part that matters is how easily a green check can borrow its good news from the very thing you plan to remove.

The green 200 had borrowed its good news from the old setting I was about to remove. When I removed it, the page went missing, because the old route had answered every request and the new shared route had served none. Two to three minutes later the new route took over and returned a real 46KB response six times in a row, and only that was proof it could stand on its own.

dxdev LESSON · paste into your AI coding agent
LESSON: A passing check that still depends on the old setup only verifies the old setup, so test the new path with the fallback removed or bypassed
SOURCE: dxdev.com/blog/2026-06-01_green-200-that-wasn-t-proof
WHAT HAPPENED: The plan was to stop keeping a separate setting for every customer web address and use one shared route instead. One address was pointed toward the shared route, the page was refreshed, and it answered with a 200, so the change was recorded as verified and the old entry was removed. The page immediately came back not found. The old temporary route had been carrying every request and the new route had served none, because the change had not yet propagated to the service in the middle. Checks from the public side still showed the page missing, and trying every variant of the address against the new shared route all worked, which ruled out an address mismatch theory. About two to three minutes later the new route took over and returned a real 46KB response, which was checked six times in a row.
THE RULE: Ask what exactly made a check pass. If the answer includes something you are about to remove, you verified the old setup. Test the new path in a way that cannot fall back on the old one, and wait for propagation before removing the fallback.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any migration or cutover that removes the old route, record, or setting after a check that either path could have satisfied.
  2. Any verification that checks only a status code and never asserts something unique to the new path, such as a header, a destination, or a response only it can produce.
  3. Any cutover step with no wait or repeat check for propagation before the old path is removed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.