agent's health check polled the old preview URL: the route moved to a new domain after deploy

TL;DR

The deploy moved the route to a new domain, but the agent's health check kept polling the old preview URL. The check 'failed' (or worse, passed against stale content) while the real deployment was healthy elsewhere. Derive the health check URL from the deploy output, not from a hard-coded URL, and the check follows the route.

The query

agent's health check polled the old preview URL: the route moved to a new domain after deploy

Use this when

• Health checks fail after a deploy that moved domains or routes.
• The old URL still responds (stale worker) so the check is misleading.
• The deploy output names a different URL than the check uses.

Not for

• DNS propagation delays (different layer).
• Health endpoint logic bugs (fix the endpoint).
• Checks against the correct URL that fail (real outage).

Steps

Step 1: Find where the new route actually serves

Read the deploy output and the current route config. Identify the live URL.

Expected result: the true serving URL. The health check's URL is stale by comparison.

Step 2: Check what the old URL serves now

Curl the old preview URL. It may serve the old worker, a 404, or someone else's content.

Expected result: you know what the agent was actually measuring. A stale 200 from the old worker is the most misleading case.

Step 3: Derive check URLs from deploy output

The deploy step outputs the live URLs. The health check step consumes those outputs as its input, never a hard-coded URL.

Expected result: the check always targets the just-deployed route. Domain moves are handled automatically.

Step 4: Re-run the health check against the live URL

Expected result: the check passes (or fails for a real reason). The signal is trustworthy again.

Step 5: Expire old preview URLs from the runbook

Expected result: no hard-coded preview URLs survive in check scripts. Every URL is either derived from deploy output or explicitly marked as a fixed production URL.

Why it happens

URLs feel permanent, so they get hard-coded into check scripts. But preview URLs are per-deployment and routes move. The agent did the diligent thing (health-checked after deploy) against the wrong address. Diligence with stale data is worse than no check: it produces confident wrong answers.

Edge cases

• The old URL serving the OLD worker with a 200 is the dangerous case: the check passes while the new deploy is broken. Version headers distinguish them.
• Custom domains can also move between workers. The 'derive from deploy output' rule covers that too.
• Keep one fixed production health check separate from the per-deploy preview check. They serve different purposes.
• If the old URL must keep working (redirects), verify the redirect target, not just the status code.

Provenance

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