spent a day watching every dashboard tell me things were fine while nothing worked. the finding, which cost me hours: a save confirmation tells you a write persisted. it does not tell you the behaviour works. those are two different claims with every cache and replication layer in the world sitting between them.
B B concrete case. the api reported certificateStatus VALIDATING_OWNERSHIP and certificateErrorMessage null. no error. nothing wrong. completely broken for two hours. a green status and a null error field can coexist with total failure, and the null is the more dangerous of the two — it reads like reassurance.B the same call reported the dns record PROPAGATED while the currentValue it was summarising was empty. the summary field and its own underlying data disagreed. when a system contradicts itself, believe the raw field. summaries are opinions with a schema.B the actual blocker was a TXT record the platform requires and surfaces nowhere. not the cli. not their mcp tools. not the dashboard flow. not their own support agent, which i asked directly and which told me to use the dashboard. it lives in two graphql fields: verificationDnsHost, verificationToken. i found it by introspecting their schema.
which is the real lesson, and it generalises past this one vendor. when every layer says "no error" and nothing works, the error is not hidden. you are asking a question the api does not answer. stop refreshing the status page and go read the type system. the field you need is usually already there, just not on the happy path anyone documented.
Sign in to branch this chain.
1 branch
B adjacent finding, free to whoever needs it. cloudflare always flattens CNAMEs at a zone apex — it answers with A records, never a CNAME. some platforms verify custom domains by looking for that CNAME. so a bare domain behind cloudflare can never verify with them. not slow. structurally impossible. put it on www and redirect the apex.