One character kept my domain dark for nine days
This site lives at amco100.me. For nine days it served nothing,
and I did not notice, because every diagnostic I would naturally reach for
reported that things were fine.
The cause was a CNAME file in the repository containing
amco1000.me. Three zeros instead of two.
Why it was invisible
GitHub Pages uses that file to decide which hostname the site answers on. With the wrong name in it, Pages happily served the site at the typo domain and returned 404 at the real one.
Here is the part that kept it hidden. I own both domains — the typo one was registered at some point and forgotten. Both sit on the same registrar's nameservers. Both resolve to GitHub's Pages addresses. So:
| Check | Result | Conclusion it invited |
|---|---|---|
| Does DNS resolve? | Yes, four A records | DNS is fine |
| Do they point at GitHub Pages? | Yes, 185.199.* | Hosting is fine |
| Is the Pages build green? | "status": "built" | Deployment is fine |
| Does the page load? | 404 | — the only failing check |
Three green signals and one red one, and the three green ones are the checks you run first when a domain misbehaves. Nothing in DNS is capable of noticing that the name in a file inside a repository is misspelled.
The second symptom I misread
HTTPS was dead on both domains — connections simply failed. I filed that mentally under "certificate not provisioned yet," which is a normal transient state for a new Pages site.
It was actually a consequence of the same bug. Pages requests a certificate
for the name in the CNAME file. The certificate that existed
covered the typo domain. The real domain had no certificate because, as far as
the platform was concerned, no one had asked for one.
So the bug produced two symptoms, and the second one had an innocent explanation ready to hand. That is worth naming as a pattern: a plausible benign explanation for a symptom is how a root cause stays hidden. I did not investigate because I had already explained it.
The fix, and the check that would have caught it
The fix was to correct one character and push. The site was live within a minute, and the certificate issued shortly after.
The check that would have caught it on day one is embarrassingly simple:
curl -s -o /dev/null -w "%{http_code}\n" https://your-domain.example/Fetch the actual page over the actual protocol you expect people to use. Everything else — resolution, IP addresses, build status — is a proxy for that question, and every proxy can be green while the answer is no.
I have since written a warning into the repository's README, directly above the file: this CNAME is load-bearing and was wrong for nine days. A comment where the mistake happened is worth more than a note in an issue tracker nobody re-reads.
The general version
Deployment pipelines are full of values that are syntactically valid and semantically wrong: a domain that exists but is not yours, a bucket name that resolves to someone else's, an environment variable pointing at a real database that is not the intended one, a region that is valid but empty.
Type checking cannot help. Validation cannot help, because the value is well-formed. The build is green because the build succeeded. The only thing that catches this class of error is exercising the system from the outside, the way a user reaches it — and doing that once, deliberately, after any change to how the thing is addressed.
Nine days is not a catastrophe for a site that had no visitors. But the same shape of mistake, one layer down, is a payment webhook posting to a URL that looks right and nobody reads. The lesson is cheap here. It is not always.