The checklist after every deploy: check the live URL

1. What happened to me, no sugarcoating

Seven guides were live and returning 200 for hours. One deploy through git, with no new commit, rebuilt from the old push and sent all seven back to 404 in one shot. I did not touch the code. No test caught it. I only found out when I opened the live URL again.

• Seven URLs that were green an hour earlier.
• One change in production, with no new line of code.
• All the routes went down together, in total silence.
• The only check that caught it: opening the URL itself in a browser.

2. The rule to set in stone

A deploy builds from the last commit that was pushed, not from the files sitting on your machine. A green build means the code compiled, not that production returns what you think it returns.

• A green build does not equal live production.
• A new deploy can overwrite existing routes if it builds from an old commit.
• "Works on my machine" proves nothing about what is live right now.
• The only proof is a real request to the real URL.

3. The checklist after every deploy

This is the core. Go through it every time, even when the deploy looks boring and fine.

• Open the production URL itself, not preview and not localhost.
• Go route by route through every page that should be live.
• Confirm the page returns 200, not 404 or a server error.
• Check that the content on screen is the new version, not blank and not stale.
• Remember that even a deploy with no new commit can change production.

4. How to check every route fast

You do not need fancy tools. A short loop over the list of URLs you commit to is enough, plus a human eye on at least one of them.

# The list of URLs that must be live
URLS=(
  "https://example.com/guides/scale"
  "https://example.com/guides/bill"
  "https://example.com/guides/route"
)

for u in "${URLS[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "$u")
  echo "$code  $u"
done

# Any line that is not 200 = red flag, open it in a browser now

5. Still open one page with your own eyes

A 200 status means the server answered, not that the page is whole. After the loop runs, open at least one critical route in a real browser and look.

• The text on screen is the new version, not a stale cache.
• No blank block, hydration error, or broken image.
• The main button or CTA actually works when clicked.
• On mobile the page does not break, because that is where most of the traffic is.

6. What to hand an agent that runs the deploy

If an agent runs your deploy for you, do not let it mark the task done based on a green build alone. Give it a done contract that forces a check of the live URL.

After every deploy:
- Do not declare "it's live" based on a green build alone.
- Open the production URL itself and check every route on the list.
- Return a table: URL, status, whether the content is current.
- If any route is not 200, stop and report before continuing.
- Remember: the deploy builds from the commit, not from my local files.

7. Keep checking even without a new deploy

The danger is not only the deploy you are running right now. Any event that triggers a rebuild in production, even without a new commit from you, can rebuild from an old commit and overwrite routes.

• Keep a fixed list of your critical URLs.
• Run a periodic status check against it, not only when you ship.
• After every settings change, integration, or automatic redeploy, check again.
• If an important page disappears, the ship is not done until you bring it back live.