How do you debug a silent CMS webhook without guessing?

My CMS said "Published just now". My site still showed the old title, and the server had received zero requests from the webhook.

I had already edited the webhook filter and rotated the secret. Nothing changed, because I was fixing layers I could not see.

Where the guessing came from

The agent I worked with could read the repo and the hosting logs, but not the CMS dashboard. Its first move was a sensible list of suspects and a request for screenshots: URL, dataset, trigger checkboxes, delivery log.

Screenshots would have worked, slowly. Each round trip means I read a UI, pick what looks relevant, and paste it. That is exactly where my own bias leaks in.

Give the agent the system's own evidence

The Sanity CLI exposes the same data as the dashboard. Once I logged in from the terminal, Claude ran two read-only commands:

sanity hook list
sanity hook logs "<webhook name>" --detailed

The first output ended the mystery in one line. The webhook URL pointed to a subdomain with no DNS record. Every delivery failed before it reached my server, and the log said only "Unknown error", with no status code.

Three layers, three separate causes

Webhook config
↓
Delivery log
↓
Dataset state
↓
Route response

After I fixed the URL, I published a test edit. No delivery appeared. Instead of retrying, Claude queried the dataset for documents updated in the last few minutes, drafts included. The result was empty: the Studio showed "Published just now" for a document with nothing new to publish.

The next real edit produced a delivery with a 401. My route returns 401 only when signature verification fails, so the secret stored in the CMS did not match the one on the server. A scheduled job using the server value still passed, which put the mismatch on the CMS side.

Each layer had its own cause. Fixing one never fixed the next, which is why my earlier edits looked like they did nothing.

Why short checks beat one big fix

Anthropic's January 2026 Economic Index report found that Claude's success rate falls as tasks take a human longer to complete. My session is consistent with that: every useful step was a single command with a clear answer.

Its March 2026 report finds evidence consistent with learning-by-doing, with experienced users seeing higher conversation success rates. In my case the missing skill was knowing that a CLI could replace the dashboard.

What this does not solve

Read access needs a login, and that login is a real credential on your machine. Getting it took three attempts: my Google account was not a member of the project, my GitHub account was. Log out when the session ends if the account can change production.

Logs also have gaps. "Unknown error" told us delivery failed, not why; the DNS check came from a separate command. At the time of writing, the secret fix still needs one real publish to confirm a 200.

Recap

1. Give the agent read access to the system's evidence (config, delivery log, data state) before asking it to fix anything.
2. Check one layer per step, and confirm each with a command that has a clear answer.
3. When a fix seems to do nothing, check whether the request reached the next layer at all.

Try it this week

Pick one integration that fails silently. Find the CLI command that prints its delivery log, and run it once before you change any setting.