How to Explain a DNS Propagation Delay in English
Learn the English vocabulary and phrases for explaining DNS propagation delays to customers, stakeholders, and non-technical colleagues during a domain or hosting change.
DNS propagation delays are one of the most common sources of confused, anxious customer messages after a domain change, a migration, or a certificate renewal — because the same domain can appear to work perfectly for one person and be completely broken for another, at the exact same moment. Explaining why that happens, in clear English, prevents a flood of duplicate support tickets and reassures people that nothing is actually broken.
Key Vocabulary
DNS propagation — the time it takes for a DNS record change to reach every resolver and cache across the internet, rather than updating instantly everywhere at once. “DNS propagation for this change can take anywhere from a few minutes to 48 hours, depending on caching along the way.”
TTL (Time to Live) — the length of time a DNS record is cached before a resolver checks for an updated value; a lower TTL means faster propagation of future changes. “We lowered the TTL to 300 seconds a day before the migration specifically so the eventual cutover would propagate faster.”
Resolver cache — a local or ISP-level cache storing DNS answers for the duration of their TTL, which is why different users can see different results simultaneously. “Your ISP’s resolver cache might still be holding the old IP address for a few more hours, even though the new record has already been published.”
Cutover — the moment the actual switch happens (like pointing a domain at a new server), separate from the moment everyone’s cache has caught up with it. “The cutover happened at 9am as planned — what you’re seeing now is just propagation delay on your end, not a failed cutover.”
Split visibility — the situation where some users see the new state and others still see the old state, due to differing cache expiration times. “We’re currently in a period of split visibility — colleagues on one network see the new site, while others still see the old one for a few more hours.”
Explaining to a Non-Technical Stakeholder
- “This is expected and temporary — DNS changes don’t apply everywhere instantly, they spread gradually as caches around the internet expire and refresh.”
- “Some people on your team might already see the new site, while others still see the old one — that’s completely normal during this window and will resolve on its own.”
- “We don’t need to take any action right now — this will resolve itself as caches expire, typically within a few hours given the TTL we set.”
Reassuring a Worried Customer
- “Nothing is broken on our end — this is a normal part of any domain change, and it should fully resolve within the next few hours.”
- “If it’s still not resolved after 24 hours, that would be unusual and worth escalating — but a few hours of inconsistency right after a change is expected.”
- “In the meantime, you can try clearing your local DNS cache or using a different network to check if the new version is already visible there.”
Explaining a Delay Timeline
- “We set a low TTL of 300 seconds a full day before the change, specifically to minimise how long this transition period would last.”
- “Because the previous record had a 24-hour TTL, some resolvers may hold onto the old value for up to a day, even though we’ve already published the new one.”
- “Full propagation is typically complete well before the TTL’s maximum window, but we always communicate the worst case so nobody is caught off guard.”
Professional Tips
- Explain WHY inconsistency is normal, not just that it is. “Different people are seeing different things because of caching, and it will resolve” is far more reassuring than “just wait, it’s fine.”
- Give a concrete time expectation, even if it’s a range. “A few hours, up to 24” is more useful than an open-ended “it’ll sort itself out eventually.”
- Proactively lower TTLs before a planned change. Mentioning this preparation step in your explanation shows the delay was anticipated and minimised, not an oversight.
Practice Exercise
- Write a two-sentence explanation for a non-technical stakeholder about why a domain change isn’t visible for everyone at the same time.
- Draft a reassuring reply to a worried customer reporting that a site “isn’t working” a few hours after a planned migration.
- Explain, in one sentence, what TTL is and why lowering it in advance of a change is a good practice.