Why your machine is the worst place to check
After you edit a record, your own resolver is the least reliable witness available. It may have cached the old answer for the length of the previous TTL, and your operating system and browser each keep caches of their own on top of that. You can be looking at an answer that stopped being true an hour ago.
That is why a change looks live for a colleague and broken for you, or the other way round. There is no single global DNS state to observe — there is a population of resolvers, each holding whatever it last fetched, expiring on its own clock.
What propagation actually is
Nothing is pushed anywhere. Your authoritative nameservers update instantly; every other resolver keeps serving its cached copy until the TTL it was handed runs out and it asks again. “Propagation delay” is just the tail of those TTLs draining at different times.
The practical consequence is that the TTL you had set *before* the change is what governs how long the switch takes — lowering it afterwards does nothing for the change you just made. And a record that resolves correctly on one resolver while another still returns the old value is not a bug; it is a cache that has not expired yet.
The TTL you set *before* the change is what governs how long it takes. Lowering it afterwards does nothing for the change you just made.
How Zeqo Watch works for you
This tool asks several independent public resolvers the same question at the same time and lays their answers side by side, so you can tell a change that is still landing from a change that never saved.
DNS is also where most site outages begin. A record edited during a migration, a nameserver change that drops a subdomain, an expired domain that takes the whole zone with it — none of these announce themselves, and all of them look like a dead website.
Zeqo Watch keeps checking the sites behind those records — uptime, response time and certificate expiry — and tells you when one stops answering, whatever the underlying cause turned out to be.