The note outlived the problem

The row read key rejected, with the provider’s own words under it: Not authenticated. Two feet above it, on the same screen, the same provider was quoting a live price and sitting mid-table in the comparison.

Both of those were correct. The key is accepted. The provider is quoting. The call that failed was one the site no longer makes.

Their rate endpoint used to answer anybody. That is not a detail — it was written into this codebase in two places as a reason why that provider could price from a deployment holding no credentials at all. Measured again, from the same machine, a minute apart:

no headers        401  {"errors":{"notAuthenticated":{"message":"Not authenticated"}}}with key headers  200  {"amountFrom":0.05,"amountTo":1.678472,"minAmountFrom":0.00083643}

No notice, no changelog, and the path is still spelled public. Nothing broke for anyone, because this deployment holds the keys. What would have broken is a deployment without them: it would have listed the provider on the board and failed every quote it made, which reads as an outage and is not one.

This is the part worth keeping. The probe for that provider did something more ambitious than check a key. It asked for the same price twice in the same moment, once with the key headers and once without, to measure whether our attribution reaches the customer’s rate — a real question, with a reassuring answer when it was last asked: identical to every digit, so what this site earns comes out of the provider’s margin rather than being added to the payer’s price.

Both calls were awaited together. When the keyless one started failing, it took the whole check down with it and printed a verdict about the key.

The site itself never makes that call. Every quote it asks for is authenticated, and has been since a fault in the other direction was fixed weeks ago. So the probe was exercising a path the product had abandoned, and was the only thing in the building still depending on it. A check that tests something the product does not use will fail before the product does, and the failure will be the check’s.

The cost of that is not the wasted hour. It is that a panel of green and red is only worth reading if red means something, and a check that cries wolf about a working credential is worse than no check at all.

The second time this row went red, the cause was the provider’s edge refusing the development machine’s address while answering production perfectly. That took a fortnight and two support emails, and it got a post of its own. It also got a standing note on the page, in the right spirit: every probe runs from whichever deployment served this screen, so red here is worth chasing only after the same screen has been opened on the live site.

That block was lifted on 28 October. The note stayed. For a week it sat above a red row with a completely different cause and explained it away — and the explanation was plausible enough that nobody tested it, including the person who had written it.

A lesson written down as a standing sentence stops being a lesson and becomes an excuse. It is dated now, and names the error it covers. The rows carry it too: away from production each one is marked, because a screenshot of a single row is how this panel actually gets quoted, and the banner does not survive the crop.

One thing is gone and will not come back. With no public rate to compare an account rate against, that measurement cannot be re-taken. The October answer stands as the answer — the two were identical, so the attribution comes out of their margin — and the note recording it now says plainly that it can no longer be checked this way.

Quoting at that provider requires the credential now, as creating already did. The two comments claiming otherwise were not wrong when they were written, which is the whole difficulty: nothing failed when they stopped being true.