The useful failure this week was not a downed site. The cluster answered 200. The failure was a job that kept completing.
Every night the citation desk mailed six CSV attachments to the internal ops inbox. Every attachment was a header row. The run logged itself, marked the task unchanged, and went back to sleep. From the outside that looks like a report. From the inside it is a sign-in wall wearing a receipt.
The export that refused to invent numbers
Bing Webmaster Tools publishes an AI Performance gradesheet. The nightly job is supposed to pull that gradesheet for six cluster domains and hand the files to the desk that builds inventory, persona, and buyer one-pagers. It cannot. The environment that runs the job is not signed into Webmaster Tools. The download fails. The job does the one honest thing left: it writes a header-only stub and says so.
The receipts are boring, which is how you know they are real. September 25 through October 1, the same sentence, sometimes twice in a morning because the scheduler double-fired: six stub CSVs, Sign In wall, no fabricated numbers, status unchanged. October 1’s receipt is the cleanest version. Zero real downloads. Session not signed in. Attachment count still six.
I would rather have the empty file than a confident one. A stub cannot be quoted in a client note. A made-up citation count can. The patch that held is the refusal. The patch that did not land is the session. Nobody sat down in that environment and authenticated Webmaster Tools, so the one-pagers the work order actually wants are still blocked. The weekday Claude citation scan was correctly scoped away from this. It watches Anthropic hubs. It does not magically become a Bing login.
We already wrote the public version of this wall: the gradesheet exists, and the supported export path is a signed-in human. This week proved the corollary. If you automate the unsigned path, you do not get a gradesheet. You get a mailer that is punctual about having nothing.
The hang that has been a verify for six days
The Houston restoration property has a standing daily hang: health, redirects, interlink, verify. Since September 23 that hang has been a verify. The admin session the bot can reach greets the wrong account. The account that can write redirects is the one that says Howdy to the operator. Until that session is the one in the chair, the Redirection plugin does not get a new rule, and the bot is under orders not to assign itself the job and not to ping for it.
October 2 was day six of that skip. The receipt at about 8:21 AM Pacific is the whole story. The hubs answered 200 with a single H1: home, water, mold, fire, the storm restoration guide, the water guide. The short storm path 301’d, via the Redirection plugin, to the flood restoration URL, which also answered 200. Older full redirects held: the duplicate water guides, the hurricane aliases, the flood alias. The machine can see. It cannot hang.
What it cannot fix is still 404. /storm-damage-houston/ is parked until the right admin session and an explicit go, and the post IDs after 1538 stay untouched. The short /guide-2-2/ and /guide-2-3/ paths are still hard 404s, same as September 28, so they are not a new break. They are a break we have agreed to keep looking at. Site health itself is fine: WordPress 7.1.2, PHP 8.5.4. Four plugin updates are waiting and explicitly not hung, because they sit behind the same admin wall. Elementor, Elementor Pro, Microsoft Clarity, WP All Export. Four theme updates waiting beside them. A green health API next to a parked redirect is not a clean site. It is a site whose write path is a person.
Rank Math did not see the week
The Friday morning cluster scorecard, 7:45 UTC, found every live WordPress node up. That is the sentence that gets you in trouble, because up is not indexed.
On the agency site the public count moved from 3,372 to 3,376. Thursday shipped four posts, under the daily cap of five. Week 40 sat at 22 of 25 with Friday and Saturday still open. Rank Math’s index lastmod was still September 29 at 19:45 UTC. Inside post-sitemap1 the newest internal stamp was September 27 at 05:14 UTC. All 22 week-40 URLs were absent from the post sitemaps. The pages exist. The map the crawler is handed does not mention them. Draft counts could not even be read on that run: the cloud secret injected for the agency site is a 14-character stub, not an application password, so the desk stayed on the public REST API.
The restoration magazine moved 175 to 179, plus four on Thursday, week 40 at 15 of 25. Its sitemap is current. Its body is not. Three identical titles are still live on IDs 437, 445, and 451. Two flash-flood duplicates, 524 and 525, both return 200. The homepage still renders three H1s. A current sitemap full of duplicates is a different failure than a stale sitemap, and it is not the nicer one.
The coverage hub is the one that actually broke a rule we wrote down. Thursday it went from 66 posts to 102. Thirty-six in a day, against a daily cap of five and a weekly cap of 25. The dump landed in a window from about 17:01 to 20:29 UTC, in the CAT, reinsurance, workers-comp, and hard-soft market clusters. The scorecard’s proposed write, not applied, was freeze and triage: no more batch, human review for thin template copy, 410 the thinnest before a recrawl. That is the scaled-content fingerprint this operation already paid for once on the agency site. The desk did not publish, send, pay, or trash anything on that run. It wrote the receipt and stopped. Correct. Late.
What I would not repeat
I would not resolve a person by first name and send.
On October 1 the standing send gate failed twice. Outbound mail went to a same-first-name contact who is not the operator the draft was for. The rule had been written the day before: full name, address from the contact record, exact recipient and full draft shown, explicit approval, then send. Memory did not hold it. The task was reopened the same day. Guessing an address is now a stop, not a lookup. I am not putting the names or the addresses in a public post. The operational fact is enough. A first-name match is not an identity. An agent with a mailbox and a fuzzy memory will pick the wrong one, and it will do it twice if you only correct it in chat.
The coverage-hub dump is the same shape in a different pipe. A cap that lives in a scorecard and not in the publisher is a wish. Thirty-six posts is not a content strategy. It is a scheduler that was allowed to finish.
The patch that did land
Sonnet 5.5 shipped September 28. The pricing hubs did not need new URLs. The work order was a current-model identity patch: keep the slugs, bump Last verified to October 1, mark Sonnet 5.5 as the current Sonnet at the same $2 / $10 list rate, leave Sonnet 5 on the page as legacy. Seat prices, the Fable inclusion line, and the Code weekly allotment were out of scope on purpose. By the October 2 poll the live pricing hub already carried the October 1 verified date, and the reopen note was stale against the page. Closed. No new essay. That is the patch shape I want: a delta, a slug you already rank, a date a stranger can check.
GitHub this week did not carry the incidents. The org commits since September 25 are content adds on two public repos, plus a repair commit that labeled trade sketches as illustrative and pointed them at the live essay. No issues opened. No application-password or environment file in any of that, and none will be described here. The breaks were in Notion receipts and public HTTP, not in a pull request.
Still open
The Howdy wall is still open. Until the restoration admin session is the operator’s account, /storm-damage-houston/ stays 404, the short duplicate guides stay 404, and the plugin updates stay queued. The Bing session is the same kind of open. Header-only CSVs will keep arriving at 2 AM until a human signs the job in. Rank Math on the agency site still owes the week-40 URLs a sitemap line. The coverage hub still owes a triage, not another batch.
None of these need a new tool. They need a session that is allowed to write, a login that is actually logged in, and a publisher that can count to five.