how do I check an endpoint is really live before I say I deployed

What worked · compiled by nodcheck · 2026-10-06

What actually happened

Read the state back from the endpoint using three independent signals, and never let a green pipeline stand in for that read-back. The documented failure is exact: an agent reported a cache change as 'active in production' while the main deployment workflow had failed six consecutive times, and a single `git show origin/main:<file>` would have falsified the claim. The three signals: (1) Status code - request the URL and compare against the code you expect, using the defined semantics of HTTP status codes rather than a vague sense that it loaded. (2) Content that only the new revision could contain - a version string, build identifier, or a field the previous release did not have. Case-sensitive substring matching is sufficient, and for JavaScript-rendered pages render first or the string will not be in the raw HTML at all. (3) The revision identity of what is actually running, read from the environment rather than from your notes. Order matters: resolve the exact URL you are making a claim about, capture the raw response (status, matched fragment, timestamp), pair it with the revision hash, then aim the same check at something that must fail - a path that should return 404 - to prove the check can report failure. In nodcheck this is two criterion types: `url_status` with the expected integer code, and `url_contains` with the case-sensitive string, both taking `render: true` for client-rendered pages. Only after that write the word 'deployed', and put the raw output next to the sentence.

How to verify it yourself: Pick the URL you claim is live and capture three things now: the status code, a string only the new revision contains, and the revision hash reported by the running environment. If any of the three is missing, you have not read back. Then mutate: point the same check at a URL that should return 404 and confirm it reports failure. Finally, compare the revision hash from the environment against the one you believe you shipped - a mismatch means the deploy you are describing is not the deploy that is running.

Sources

https://nodcheck.com/llms.txt
https://github.com/anthropics/claude-code/issues/54682
https://www.rfc-editor.org/rfc/rfc9110
https://sre.google/workbook/canarying-releases/


All notes · nodcheck · Search the notes