Four of 25 domains stalled in pending_validation with no error to read

One domain sat in pending_validation for about thirteen hours, and the validation error field was null the entire time.

The field that should have explained the stall was empty. We were moving customer domains onto Cloudflare and our own relay, one batch at a time, without taking any site down. For each domain the routine is the same. Register the hostname with Cloudflare, publish an _acme-challenge TXT record so the certificate authority can prove the domain is ours, wait for the certificate to go active, and only then flip the traffic. The site stays on its old origin until the certificate is live, so a domain that sticks is never an outage. It just doesn’t move.

The check that came back clean

The stuck domain had our TXT record published, and it resolved from outside. Our DNS looked fine and Cloudflare said nothing was wrong. When we rechecked at around the twelve hour mark, Cloudflare was listing two validation tokens for the hostname. We wrote that down as token rotation. In the same note we still called it a Cloudflare or certificate authority side wedge, because our DNS was clean.

That conclusion was wrong. Cloudflare rotates the expected token if the first validation window lapses, whether from a slow publish, DNS propagation, or its own backoff. Our TXT record held the token from before the rotation. It existed and it resolved, but it wasn’t the record Cloudflare was now waiting for. We had checked whether our record was published. The question that mattered was whether it matched.

Four more in the ramp-up batch

Later that day we ramped to 25 live domains in one batch. All 25 went through with zero downtime, but four of them stalled in the same state, pending_validation with a null error, for the same cause. In that batch, 16% had their token rotated out from under them.

For those four, we asked Cloudflare for each hostname’s current expected token, published it alongside the stale one, and waited again. Cloudflare accepts any matching TXT record at that name, so we didn’t have to delete the old ones. All four validated and flipped.

The thirteen hour domain behaved differently. Publishing the current token did not move a hostname that stale, so we deleted it and registered it again from scratch. The fresh registration got a new validation window and the certificate was active in about a minute.

Making the comparison a command

Four more stalls in one batch made this a pattern, so the check became a first class step. A reconcile command returns Cloudflare’s current expected token for any domain. The wait step now prints that token for anything still pending past its window, instead of timing out and reporting nothing. Anyone can compare it with what sits in the zone and see the mismatch in one command.

We also started recording how long each domain takes to go active, so a batch can be planned against real numbers.

The empty error field was where we had stopped looking that day. The step that catches it now shows the token Cloudflare wants next to the one we published.

A published DNS record is not proof that validation will pass, because Cloudflare can rotate the expected token while the old record still resolves. When a domain sits in pending_validation with an empty error, compare the token in the zone with the one Cloudflare currently expects before blaming the certificate authority.

dxdev LESSON · paste into your AI coding agent
LESSON: An Empty Error Field Means the System Has Nothing to Say, Not That Nothing Is Wrong
SOURCE: dxdev.com/blog/certificate-said-nothing-wrong-thirteen-hours
WHAT HAPPENED: While moving customer domains onto Cloudflare for SaaS, one custom hostname stayed in `ssl_status=pending_validation` for about 13 hours with `validation_errors: null`. The `_acme-challenge` TXT record we had published was live and resolvable. We checked that our DNS was clean, saw that Cloudflare now listed two validation tokens, and recorded the problem as a Cloudflare or certificate authority side wedge. It was neither. If the first validation window lapses, Cloudflare rotates the expected token, and the record we had published was stale. Later that day 4 of 25 domains in a batch stalled the same way. Fetching Cloudflare's current expected token and publishing it fixed all four.
THE RULE: When a validation is pending with no error, compare what you published to what the system currently expects, not to what it expected when you published. A record that exists and resolves is not evidence that it is the right record.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any wait loop that times out on a pending state without fetching the system's current expected value.
  2. Any diagnosis note that blames a third party without comparing your published value to the provider's current one.
  3. Any long-running verification with no tiering of how long is normal, so a 13 hour stall looks like a 13 minute one.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.