---
type: blog
title: "DNS Propagation Time: When to Wait and When to Fix"
description: "Your new store domain works on one network but not another. Learn which DNS checks justify waiting and which problems need a correction before launch."
date: "2026-10-10"
lastModified: "2026-10-12"
authors: "Runner AI Team"
tags: ["DNS", "Store Launch", "Store Operations"]
featured: false
readTime: "6 min read"
thumbnail: "https://storage.googleapis.com/runner-blog/blog/dns-propagation-time/cover"
thumbnailAlt: "A storefront at the center of a globe with resolver nodes showing checks, clocks, and one warning, beside a large clock"
seo:
  title: "DNS Propagation Time: A Store Launch Troubleshooting Guide"
  description: "Understand DNS propagation time before launching your store. Check cached records, ownership verification, and HTTPS to decide whether to wait or fix the setup."
---

DNS propagation time is the delay before DNS lookups reflect a changed record. Updates can appear within minutes or hours, but GoDaddy advises allowing up to 48 hours for its DNS changes. That is planning guidance, not a countdown for every domain. For a store launch, separate cached answers from incorrect records, ownership verification, and HTTPS readiness before deciding to wait.

If your store opens on mobile data but shows the old site on office Wi-Fi, caching is a plausible explanation. If the DNS provider still returns the wrong destination, more waiting won't correct it. Our recommendation is to check the saved records first, then wait only when the evidence points to caching.

## What determines DNS propagation time?

A DNS resolver looks up a hostname and can cache the answer. The record's time to live, or TTL, tells it how long to retain that answer before requesting a fresh one. Different resolvers can hold answers from different moments, so two customers may temporarily reach different destinations.

[Cloudflare's TTL documentation](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) explains this tradeoff. Longer TTLs make cached answers more likely, but changes take longer to reach users. It also warns that a local DNS cache can delay what you see even when the record's TTL is five minutes.

For example, suppose a resolver cached your old website address with a one-hour TTL just before you changed it. That resolver may still use the old answer during that hour. Lowering the TTL in the new record does not retroactively change the answer it already cached. For a planned move, lower the TTL in advance and allow the previous TTL to expire before changing the destination.

Changing a nameserver is a different operation from editing an A or CNAME record. It changes where DNS answers come from, rather than just one answer. [GoDaddy's propagation guidance](https://www.godaddy.com/help/what-factors-affect-dns-propagation-time-1746) identifies TTL, internet-provider caching, and registry updates as timing factors. Check your provider's guidance for the change you actually made; do not apply a nameserver estimate to every record edit.

## Should you wait or correct the setup?

Start with the exact hostname you are connecting. `example.com` and `www.example.com` are separate names. A successful lookup for one does not prove that the other is ready.

Compare the required record type, host, and value with the saved record at the DNS service your domain's nameservers use. Your registrar and your active DNS service may be different companies. Editing a zone that isn't authoritative for the domain won't change the answers customers receive.

| What you observe | What it suggests | Next action |
| --- | --- | --- |
| Active DNS has the correct record, but public resolvers return mixed old and new answers | Cached answers may still be expiring | Record when you changed it and recheck after the relevant TTL |
| Active DNS returns a wrong value or has no required record | The setup needs correction | Fix the type, host, or value before waiting |
| The root domain works but `www` fails | One hostname may be missing its setup | Check each hostname and its intended redirect separately |
| Routing records match, but the platform requests an ownership record | Ownership has not been confirmed | Add the exact challenge record the platform supplies |
| DNS points to the intended host, but HTTPS shows a certificate error | DNS success has not proved HTTPS readiness | Check the hosting platform's certificate status and troubleshooting guidance |
| The store's existing published address also fails | The problem may be unrelated to the custom domain | Investigate publishing or the storefront before changing more DNS records |

A propagation checker samples answers from multiple locations. Select the record type you changed and compare returned values, not just green marks. A checker can show that a name resolves without proving it resolves to the destination your platform requires.

If you have technical help, ask them to compare the authoritative answer with answers from several recursive resolvers. Save the hostname, record type, expected value, observed values, and timestamps. These make a support request more useful than "the domain isn't working."

Avoid repeated speculative edits while you investigate. They create several possible destinations and make it harder to identify which change a cached answer represents. Preserve working email records and other unrelated records; connecting a storefront is not a reason to replace the entire DNS zone.

## DNS success is only one store-launch check

A domain connection involves more than resolving a name. The platform must associate it with the intended store, confirm any required ownership challenge, and serve HTTPS correctly. After that, the storefront still needs to work at that address.

Runner AI's [custom-domain guide](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/custom-domains) makes this distinction explicit. Attaching an owned domain does not by itself confirm a live connection. Routing records and ownership verification are checked separately. Follow that guide for the current connection controls and the exact records supplied for your domain, rather than copying an IP address or TXT value from an article.

For the short version of those steps, see [connect your custom domain in Runner AI](./launch-online-store-10-minutes-no-code#step-5-connect-your-domain-5-minutes) in our store launch guide. It covers the free Runner address, a domain you already own, and buying a domain through Runner.

Consider an illustrative failure: your CNAME points to the required host, but the platform still asks for a TXT ownership record. Waiting another day does not supply the missing proof. Complete the challenge first. Conversely, if the required records are correct and different resolvers return old and new answers, a measured wait is reasonable.

Before announcing the custom address, check it on a second network. Open the homepage and a product, add an item to the cart, and follow the checkout path. If you place a test order, use your payment provider's documented test procedure. A certificate or domain-status check does not prove that checkout succeeds.

Keep the old storefront available during a planned move until the new route and customer flow are verified. For Runner-specific acceptance steps, use [verify the live store and checkout](https://www.runnerai.com/docs/en/guides/storefront-and-publishing/live-store-and-checkout). For broader planning, read our [secure ecommerce website checklist](./secure-ecommerce-website). If you are evaluating where to host a store, the [ecommerce hosting feature page](https://www.runnerai.com/features/best-ecommerce-hosting) covers that separate decision.

## Related questions

### Does DNS always take 48 hours?

No. DNS propagation time depends on the record, its previous TTL, the resolver, and whether you changed nameservers. GoDaddy describes a few hours as usual and allows up to 48 hours in its guidance. Use that as a planning allowance, not proof that an incorrect record will repair itself. Check the authoritative setup before starting a wait.

### Can I make a DNS change appear faster?

For a planned change, reducing TTL in advance can shorten later cache retention. It cannot recall an old answer already cached elsewhere. Clearing your local cache may change your own result, but it does not clear customers' resolvers. Check the provider's supported TTL settings and keep the previous destination healthy during the transition.

### Why does a DNS checker pass while my store still fails?

The checker may be testing a different hostname or record type. Even a correct routing answer does not prove domain ownership, a valid HTTPS certificate, or a working storefront. Compare the returned destination with your platform's required value, then inspect ownership and certificate status. Finally, test the customer flow at the exact public address you intend to share.

### When should I contact support instead of waiting?

Contact support when the saved setup is correct but the platform remains blocked, or when the delay exceeds your provider's guidance. Include the hostname, change time, required records, lookup results, and exact error. If active DNS returns the wrong destination, correct it first. If the original published address fails too, report that distinction so support can investigate the right layer.