When to use it
A domain returns Cloudflare 522/525, shows an old version, or a custom domain is stuck “pending”. These incidents are usually configuration, not code, and the fastest path is a careful read-only checklist.
Investigator brief
Task: find out why <DOMAIN> is <SYMPTOM>. Read-only: do not change DNS, deployments, domains or code.
Check, in order, and record each result:
1. curl -sI https://<DOMAIN>/ and https://www.<DOMAIN>/ : status, server header, cf-ray.
2. Which hosting project serves this domain (Pages project / Worker route / origin server)?
If none claims it, the DNS points at an origin that no longer answers (typical 522/525).
3. For a Pages project: production branch, latest production deployment (date, commit, status),
and whether recent deployments are only Preview (branch mismatch).
4. DNS records for the domain (if your token can read them); otherwise say so.
5. Compare the live HTML with the repo's main branch: same version or not?
Report: cause, evidence, the exact fix (who must do what, in which console), and the risk of the fix.
Approval rules
Everything that would change state is high risk by default (api.cloudflare.com calls, wrangler pages deploy, ssh). For triage, make it stricter:
{
"rules": [
{ "id": "triage-read-only", "risk": "critical", "description": "Triage sessions never write",
"tool": "^Bash$", "command": "wrangler (pages )?(deploy|publish)|-X (POST|PUT|PATCH|DELETE)", "project": "triage" }
]
}
Done when
- A one-paragraph cause, with the evidence that proves it
- A fix a human can apply in under ten minutes, or a list of what only the account owner can do
Lessons from real runs
- “Production branch ≠ the branch you push” made every deploy a Preview: the site looked frozen for weeks.
- Domains with no host behind them (registered, added to Cloudflare, never bound to a project) give 522 at the apex and 525 on www.
- A token that can deploy Pages may not be able to read DNS. Say what you could not check instead of guessing.