Ask eighteen independent resolvers what they are holding, compare it against your own nameservers, and see how long the stale caches have left.
DNS does not propagate. Nothing is pushed anywhere. When you change a record, your nameservers start serving the new value immediately, and that is the whole of the change on your side. Everyone else keeps using the answer they already have until it expires. Every resolver that looked your record up cached it along with a countdown, the TTL, and until that countdown reaches zero it will keep giving out the old value without asking you again. "Waiting for propagation" is waiting for other people's timers to run out.
That is why this page asks eighteen resolvers rather than drawing a map. The well-known sites in this category show a flag beside each resolver, and it is largely fiction: Google, Cloudflare, Quad9 and the rest run anycast, so 8.8.8.8 answers from whichever of their sites is nearest to whoever asked. Query them all from one place, as every such site does, and every pin on the map is secretly the same pin. What actually varies between them is not geography, it is cache state, and cache state is the thing you are waiting on.
So this compares two things properly. Every resolver's answer is checked against your domain's own nameservers, asked directly, so the page can tell you who is current rather than showing you eighteen opinions and leaving you to guess. And because a cached answer carries the seconds left on it rather than the TTL you configured, the longest of those numbers across the stale resolvers is exactly how long until the last of them comes back and asks again. That is the answer to "when will my change be live", and no map can give it to you.
One caution the other tools get wrong. Quad9, AdGuard, CleanBrowsing and Comodo block domains on policy, and a blocked domain comes back as though it does not exist. Counting that as "not propagated" sends people to re-check DNS that is correct everywhere, so those resolvers are marked here and their refusals are left out of the count.
As long as the TTL that was on the old record when it was last cached, and no longer. If your record had a TTL of 3600, a resolver that fetched it a minute before your change will serve the old value for another 59 minutes. This page shows the actual seconds left on each stale cache, so you do not have to guess.
Only in advance. Lower the TTL a day before you make the change — to 300, say — wait for the old, longer TTL to expire everywhere, then change the record. Everyone picks it up within five minutes. Lowering the TTL at the same time as the change does nothing, because the resolvers holding the old record are also holding the old TTL.
No, that is the normal middle of a change. Each cache expires on its own clock, so they update at different moments over the length of the TTL. It is only worth investigating if a resolver is still stale well after the longest TTL shown here has passed.
Because they are different caches. 1.1.1.1 and 1.0.0.1 are both Cloudflare and do not share one copy of your record; we have seen the same record on both with 135 and 10 seconds left. That is why the summary counts operators separately from addresses.
Yes. Any name, and A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, SRV or PTR. TXT is the one people check most after a change, because that is where domain verification and SPF live.
Either the name has no nameservers we can find, or none of them answered on IPv4 within four seconds. The page says which, and falls back to reporting what most caches agree on — labelled as such, because a majority of caches can all be holding the same stale record.