Two to three minutes of 404 after removing a setting we were sure was dead

We changed where a customer’s web address was meant to go, refreshed the page, and got a green 200. A 200 is a website’s shorthand for “the page answered okay.” The page loaded. We wrote down that the change was verified and moved on.

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

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

What we were changing

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, which was meant to be simpler and easier to keep up to date. Before removing the old label, we pointed the address 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 carrying the whole load. We treated a successful page load as proof of the first possibility without ruling out the second.

Removing the old entry

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

Our first check had failed us, 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 to feel the difference between having evidence and seeing something we wanted to believe.

Chasing the wrong story

We 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 about which address it was asked for. Both were reasonable stories. Neither was a fact yet.

So we 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 the address on the request might be steering people to different places.

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

The boring answer

The change had simply not finished taking effect everywhere. Technical people call that propagation lag. In ordinary words, the instruction had been sent, but the service in the middle had not received it 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 we had just seen. We checked it six times. It worked six times in a row. Only then did we have the proof we thought we had at the start.

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

A delay of a few minutes is something we can plan around next time. What stays with us is how easily a green check can borrow its good news from the very thing you plan to remove.

What the check showed

A green 200 showed that something answered, not that the new route did. The old route had answered every request and the new shared route had served none, which only came out once the old entry was gone.

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/everyday-ai/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.