On the morning of August 15, 2026, a message arrived from Spain.
"Your MCP server is dead. 522."
My own monitoring showed seven days of green. Every nightly sample said reachable: true. So either someone was lying, or an instrument was broken. That is what you would assume.
Here is the conclusion up front: both reports were correct. And the contradiction between them lit up a boundary that neither side could have found alone. This article is the full account, and the record of what I did with the incident instead of burying it.
Background
I am a carpenter in Hiratsuka, Japan. Thirty years on job sites. These days I also run an MCP server that gives AI agents a third party fair price check for construction estimates, and a verification gate (hs-verify-gate) that measures every endpoint on a public register nightly and publishes the results as they come. My own servers are measured under the same rules.
Witness A: the operator's gate
Invoked by Cloudflare cron, measuring nightly from inside the same Cloudflare account. Real samples from the public history:
2026-08-09T01:18:56.366Z reachable: true record_sha256: d4ff4a21...
2026-08-13T18:00:38.235Z reachable: true record_sha256: 4d204e6a...
2026-08-14T18:00:38.072Z reachable: true (nightly sweep, six endpoints, all reached)
A week of green. Every sample honest, every sample hashed.
Witness B: babyblueviper1
From his own network, plain curl, invoking the gate's public HTTP check. His report:
reachable: false
mcp_endpoint: initialize failed: http 522
agent card fetch: 522
And before trusting any of it, he recomputed the gate's record_sha256 himself: removed the two excluded fields, canonicalised, hashed, confirmed the match, and only then reported. You will not find better manners in a witness.
The operator's reproduction
I reproduced it the same day.
2026-08-14T23:18:50.259Z gate /check to target reachable: false, http 522
same minutes direct initialize to target HTTP 200
2026-08-14T23:22:44.151Z gate /check to second same-zone endpoint identical 522
gate /check to off-zone host reached (405, as expected)
The target was up the whole time. Two commercial liveness monitors and a residential client were receiving 200s from it in the same window. Only the gate's HTTP-invoked checks failed.
The mechanism
Cloudflare Workers has a guard against subrequest loops, and that guard keys on the zone the incoming request arrived on. Three rules, all measured:
HTTP entry (zoned) to same-zone custom domain : blocked, 522
cron entry (no zone) to same-zone custom domain : allowed
any entry to the same worker (self) : blocked
Witness A measured from a context the guard permits. Witness B triggered a context it blocks. Both reported exactly what their vantage showed.
And here is the point: neither could have discovered this boundary alone. The operator's week of green could never surface the guard. The external 522 alone could never locate it. Two honest, conflicting reports had to exist at the same time before the boundary became knowledge.
The fix
Fixed on August 15, 2026, in public.
HTTP-invoked probes to endpoints on my own zone now route through a relay worker outside the zone path, every hop on the public edge. And every verdict since carries three things:
probed_via, disclosing the route that measured it. The vantage is part of the measurement.
reachable: null when the instrument itself fails, so an instrument failure is never recorded as a target failure.
gate_commit, the commit that produced the verdict, included inside the hashed record.
The repair history is public in the repository (commits 2a1dfc91 through 8b0b5fc2). As a consequence of the fix, the gate measured its own endpoint for the first time.
Lessons
A green history only means green from that vantage. Monitoring that hides its vantage misleads honestly.
A single witness can err while reporting honestly. Two conflicting witnesses cannot both be dismissed.
Never record an instrument failure as a target failure. If you could not reach it, the answer is reachable: null.
What I did with the incident
I did not bury it. I inverted it.
The full account became Discrepancy Record 0001, anchored as entry 20 on a public ledger, confirmed at Bitcoin block 962511 (2026-08-15 02:44 UTC). You can verify it right now:
curl -s "https://ledger.horizonshield.dev/ledger/20?format=raw" | shasum -a 256
The hash you get back matches this:
4b58ec1e04ec8a987826dbaa9fd334c0239ab3cd426363695fc853c65d0fd13e
The ledger is called NENRIN, the Japanese word for tree rings. The specification is anchored as entry 19 at Bitcoin block 962507. The mechanism fits in three lines. Anyone can measure my servers from outside and submit the observation to the ledger. The code has no route for me, the operator, to refuse a valid submission. Every record carries a Bitcoin anchored timestamp, so nothing can be painted in afterwards.
The caps are stated, not hidden: 64KB per record, 50 a day, 5 per IP. Invalid signatures are rejected. Unsigned records are accepted and marked unsigned.
A tree adds one ring a year, and nobody can paint one in afterwards. That is why rings prove age. This 522 taught me that trust in a service can only accumulate the same way.
An invitation
If you run monitoring or measurement of any kind: your observations can become permanent, citable records under your own name and vantage. If your report conflicts with what my own gate says, that is the best possible submission. Discrepancies are not an embarrassment here. They are the product.
Witness intake (GET returns a self description): https://ledger.horizonshield.dev/witness
The ledger: https://ledger.horizonshield.dev/ledger
Code and full text: https://github.com/ogasurfproject-jpg/horizon-shield
