web-deploy-verification

Poll the production URL in a bounded background loop, checking for a string that only exists in the new version such as new copy, a new route, or a new DOM id. Only report the change as shipped once the marker appears, and treat a timeout as a signal to inspect the deploy pipeline.

Deploys typically take 30 seconds to 5 minutes depending on the platform. Use a polling loop with a ceiling generous enough for the platform's typical build time, such as 40 iterations of 20-second sleeps, rather than checking once immediately after merging.

Sandboxed environments often set HTTPS_PROXY, which causes headless Chromium navigation to public URLs to stall. Instead of configuring browser proxy settings, build the same commit locally and screenshot it via localhost, since loopback traffic bypasses the proxy entirely.

No. A successful CI run only proves the code compiles; it says nothing about whether the deploy step ran or ran against the correct commit. Always confirm the change on the real production URL rather than trusting the CI dashboard.

Choose a string unique to the new version, such as new copy, a new route, a new asset filename, or a new DOM id or class. Markers present in both old and new versions, like the site name or nav links, will report success immediately regardless of whether the change deployed.