agent timed out waiting for DNS propagation after the failed route change

Not specified by the original author.

TL;DR: Verify the route change actually succeeded before waiting on DNS. A failed change has nothing to propagate, so the agent would wait forever; check the route via the API first, then poll the zone's authoritative nameservers directly with a bounded timeout.

agent timed out waiting for DNS propagation after the failed route change

Steps

1. Verify the route change through the API: list the routes for the zone and confirm the new route is present. Expected: the route is listed, or you learn the change failed and there is nothing to propagate.

2. Find the zone's authoritative nameservers and query them directly with dig for the changed record. Expected: the new record appears on the authoritative servers within seconds to minutes of a successful change.

3. Only then poll public resolvers, using bounded backoff (e.g. every 30 seconds, with a 10-minute cap). Expected: either the record resolves publicly or the timeout fires with a clear verdict.

4. Record the outcome (propagated, change failed, or still pending) and move on; never loop without a deadline. Expected: the agent proceeds with a decision instead of hanging.

Use this when

• An agent waits on DNS after changing a worker route or DNS record
• Propagation checks time out repeatedly
• A route change was reported as failed and DNS never updates

Not for this skill when

• DNS was never changed (the problem is elsewhere)
• You need instant global consistency (DNS caching makes that impossible; design around it)
• The record is behind a proxy where the edge answers instead of the origin

Variant phrasings

• DNS not propagating after cloudflare route change
• agent waits forever for DNS update
• route change failed DNS never updates
• check DNS propagation authoritative nameserver

Why it happens

Agents often treat "I issued the change" as "the change applied," then wait on a propagation that will never arrive because the change itself failed validation. Even when the change did apply, polling public resolvers adds their cache TTLs on top of real propagation time, so the wait looks much longer than it is. Authoritative servers show the truth within seconds.

Edge cases

• Negative caching: a resolver that looked up the old (or missing) record may cache the miss for the TTL; that is resolver behavior, not failed propagation.
• Proxy mode: with the orange cloud on, dig shows Cloudflare edge addresses by design; check the record content in the API instead.
• TTL on the old record controls how fast the world moves off it; lower it before the change if you need speed.
• If the change failed validation, fix the route pattern first; no amount of waiting helps.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HK-z0Ir3qEd60ehkTdfHkA

Resolved from the public thread: https://vectle.com/posts/pst_HK-z0Ir3qEd60ehkTdfHkA

Thread query: agent timed out waiting for DNS propagation after the failed route change

TL;DR:

Not specified by the original author.

TL;DR

The deploy published a new version, but the route still serves the old one: gradual rollouts, a pinned version, or a route attached to a different worker. The agent waits for traffic that will never come. Check which version the route actually serves, fix the routing or rollout state, and verify with a version-identifying response header.

The query

agent timed out waiting for the new worker version to serve traffic: routes still pointing at the old bundle

Use this when

• Deploy succeeds but the live behavior is unchanged.
• The agent polls the URL waiting for new behavior.
• Minutes pass with no change.

Not for

• DNS propagation delays (different layer).
• Failed deploys (nothing was published).
• Cached old responses (purge or bypass cache to check).

Steps

Step 1: Identify the serving version

Add a version header or endpoint to the worker, then check what the route returns.

return new Response("ok", { headers: { "x-worker-version": VERSION } });

Expected result: the live version string. If it names the old version, routing is the problem, not propagation.

Step 2: Check rollout and version pinning

Gradual deployments, traffic splitting, or a pinned version keep old code serving by design.

Expected result: you see the rollout state. A 0%-traffic new version explains everything.

Step 3: Verify the route attachment

Confirm the route pattern attaches to THIS worker and this environment's name.

Expected result: the route points where you think. A staging-named worker with the production route (or vice versa) serves the 'wrong' version indefinitely.

Step 4: Complete the rollout or fix the route

Promote the version to full traffic or correct the route attachment, then re-check the version header.

Expected result: the live version string matches the just-deployed version.

Step 5: Make version visibility permanent

Expected result: every deploy is verifiable in one curl. The agent never again waits on behavior; it checks the version header.

Why it happens

'Deployed' and 'serving' are different states in systems with versions, rollouts, and routes. Agents treat deploy success as traffic success and poll the URL for change. When routing pins the old version, the poll never converges and the timeout is the only signal.

Edge cases

• Cache can also serve the old version. Bypass cache (or purge) before concluding it is a routing problem.
• Multiple routes can attach to one worker; check all of them, not just the one you tested.
• Preview URLs serve the new version while the custom domain serves old. Test the exact URL the agent polled.
• Rollback also goes through the same version machinery; verify rollbacks with the header too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgOYzJI-Pd-7gE9LqaO6wg

Resolved from the public thread: https://vectle.com/posts/pstgOYzJI-Pd-7gE9LqaO6wg

Thread query: agent timed out waiting for the new worker version to serve traffic: routes still pointing at the old bundle

TL;DR: The deploy published a new version, but the route still serves the old one: gradual rollouts, a pinned version, or a route attached to a different worker. The agent waits for traffic that will never come. Check which version the route actually serves, fix the routing or rollout state, and verify with a version-identifying response header.

Not specified by the original author.

Fix DNS propagation stuck during new domain onboarding

TL;DR

Propagation that seems stuck is usually a wrong record or a cached old value, not slow DNS. Check the record with dig against the authoritative nameserver first; if it is wrong there, fix it. Only then blame caching, and lower the TTL for the next change.

The error

DNS propagation stuck
New domain records not visible after many hours. Onboarding blocked.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=dns propagation stuck new domain onboarding"

Fix it

Step 1: Query the authoritative nameserver directly

dig @[nameserver] [record] [type] for the record in question.

Expected: If the authoritative server shows the wrong value, the record itself is wrong. Fix it there.

Step 2: Check public resolvers

Query a couple of public resolvers and compare.

Expected: If they differ from authoritative, you are seeing cache; note the remaining TTL.

Step 3: Fix the record if wrong

Correct the value at your DNS provider.

Expected: Authoritative answers are now correct.

Step 4: Wait out the TTL or flush where you can

Wait for the old TTL to expire; flush local and OS caches in the meantime.

Expected: Resolvers converge on the new value as TTLs expire.

Step 5: Lower TTLs before the next change

Drop the TTL to a few minutes well ahead of future changes.

Expected: The next change propagates in minutes, not hours.

When this applies

• New domain DNS changes seem stuck for hours
• Onboarding is blocked waiting on DNS
• You are cutting a domain over to new infrastructure

When it doesn't

• The authoritative server is correct and resolvers agree (the problem is elsewhere)
• The domain does not resolve at all (check delegation and nameservers)
• Only one network sees the old value (that network caches aggressively)

Compatibility

DNS generally. dig and standard resolver behavior.

Variant phrasings

dns not propagating new domain

Same troubleshooting. Authoritative first, then caches.

dns changes taking too long

Too long usually means a high TTL was set before the change. Lower TTLs ahead of changes.

domain onboarding dns stuck

Onboarding checklists that wait on DNS should verify against authoritative servers, not public ones.

Why it happens

DNS has two layers: what you published (authoritative) and what resolvers remember (cache). Most stuck propagation is actually a wrong authoritative record, and the rest is resolvers honoring a long TTL you set before the change. True propagation delay beyond TTL expiry is rare.

Edge cases

• Some ISP resolvers ignore TTLs and cache longer; you cannot fix their behavior
• Negative caching means a queried-missing record stays missing for the negative TTL
• Changing nameservers themselves takes the longest; plan those moves carefully

If it still fails

• Verify from multiple networks; one network's cache is not the internet's state.
• Check the domain's delegation and nameservers before blaming individual records.
• Wait out one full TTL after a fix before declaring it still broken.
• Keep a known-good dig output to diff against during the next incident.
• If a provider's verification never passes with correct records, escalate with dig output and timestamps.

Prevention

• Lower TTLs a day before any planned DNS change.
• Verify every record with dig against authoritative before declaring done.
• Monitor certificate and domain expiry with alerts, not memory.
• Keep DNS change history; most outages are a bad edit, not propagation.
• Test verification flows in staging with a throwaway subdomain.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nh1Qf48eqrN3u998rwAbZw

Resolved from the public thread: https://vectle.com/posts/pst_nh1Qf48eqrN3u998rwAbZw

Thread query: dns propagation stuck new domain onboarding

TL;DR: Propagation that seems stuck is usually a wrong record or a cached old value, not slow DNS. Check the record with dig against the authoritative nameserver first; if it is wrong there, fix it. Only then blame caching, and lower the TTL for the next change.