New subdomain scamcheck.asquaresolution.com propagated in some regions after 20 minutes but took 4 hours to fully propagate globally. Caused inconsistent test results and premature go-live.
Impact
scamcheck.asquaresolution.com was announced as live after 20 minutes but remained inaccessible to users on resolvers that had not yet propagated the new CNAME record. Reports of 404 and 'site not found' from some users while others had it working. Inconsistent behavior continued for approximately 4 hours after the DNS record was created.
Root Cause
DNS propagation is not instantaneous or globally uniform. Different resolvers (ISPs, Google 8.8.8.8, Cloudflare 1.1.1.1) cache records with different TTLs and refresh at different intervals. The CNAME record had propagated to local resolvers within 20 minutes, which made the site appear live locally. Other global resolvers had not yet picked up the change.
Resolution
Waited for full propagation. Verified using dnschecker.org before confirming the domain as live. Used whatsmydns.net to check CNAME resolution from multiple global server locations. Established a minimum 2-hour wait policy before marking any new DNS record as fully live.
Prevention Pattern
After creating a DNS record, check propagation using dnschecker.org or whatsmydns.net — do not rely on your own browser. Wait until at least 90% of checked locations show the correct record before announcing the domain as live. Add an additional 15-30 minutes for GitHub Pages HTTPS certificate provisioning after DNS propagates.
Recovery
Complex (hours)
Deploy risk
medium
Detectable
Appears resolved after 20 minutes, fails for other regions/users
Repeat risk
high
Prevention patterns
Ecosystem impact
Related failures
ScamCheck was ready to go live at scamcheck.asquaresolution.com. The GitHub Pages deployment was complete, the CNAME file was in the repository, and the DNS record was created: a CNAME pointing scamcheck.asquaresolution.com to asquaresolutions-beep.github.io.
Twenty minutes after creating the record, the subdomain loaded correctly in the local browser. The deployment was announced as live.
Within the hour, reports came back: some users were seeing "site not found," others a 404, and some had it working fine. The same URL, different results depending on who was asking.
When a DNS record is created or changed, the update does not instantly broadcast to every DNS server on the internet. Instead:
TTLs vary. A record with a 3600s TTL can sit stale in a resolver's cache for up to an hour. Lower-TTL records propagate faster. The record that was created had a TTL of 3600 — meaning some resolvers could hold an empty cache for up to an hour before checking for the new record.
The result: the domain works for users on resolvers that have already queried and cached the new record, and fails for users on resolvers that haven't. Twenty minutes is enough time for local and some major resolvers. Full global coverage typically requires 2-4 hours, sometimes longer.
⚠Your browser is not a reliable propagation check
Your local DNS resolver is often one of the fastest to pick up new records — especially if you use Google or Cloudflare as your resolver. Seeing the site load locally after 20 minutes tells you your resolver has the record. It says nothing about the rest of the world.
Two tools that check a DNS record from multiple global server locations simultaneously:
The workflow:
There is a second time-gate that compounds the propagation delay: the HTTPS certificate.
GitHub Pages provisions Let's Encrypt certificates automatically for custom domains. This process cannot begin until DNS propagation is sufficiently complete — GitHub's servers need to be able to resolve the domain and verify ownership. Certificate issuance typically adds 15-30 minutes after DNS propagates.
Until the certificate is issued, the domain serves over HTTP only, or shows a certificate error in browsers that enforce HTTPS. The GitHub Pages settings page shows the HTTPS status clearly: the "Enforce HTTPS" checkbox is greyed out until the certificate is ready.
Both conditions must be met before the domain is truly live:
After creating any new DNS record:
The 2-hour wait feels slow. Announcing 4 hours late because of inconsistent user reports feels slower.
Fix Confidence
Recovery Complexity
Pattern Family
This failure belongs to a named recurring pattern. Other failures in this family share the same root cause structure — understanding the pattern prevents multiple failure types simultaneously.