Building Apps with AILesson 46 of 87

Contents

Building Apps with AI

Lesson 46 of 87. Sign in to keep your place.

Module 5 · Save points, and shipping to a stranger

Which version is live

8 min read

I pushed and nothing changedBuild failedThe last gooddeployment isstill servingWrong branchOnly theproductionbranch becomesthe live siteStale pageHard refresh, ora private windowBuild-timevalueA variablechanged withouta redeployThe changeitselfIt did not dowhat you thinkit didCheck them in this order. The last one is only reachable once the four before it are excluded, and itis where most people start.
Check them in this order. The last one is only reachable once the four before it are excluded, and it is where most people start.

Figure

I pushed and nothing changed

Five causes, in the order to check them.

  1. The build failed. The host keeps serving the last good deployment, so the site looks unchanged rather than broken. Nothing tells you unless you look, or unless you turned on the email notification.
  2. You pushed a different branch. Only the production branch, usually main, becomes the live site. Everything else becomes a preview.
  3. Your browser is holding the old page. A hard refresh, or a private window, settles it.
  4. The change was to a build-time value. A variable edited on the dashboard without a redeploy, from the previous lesson.
  5. The change did not do what you think. Only reachable once the four above are excluded.

Reading the deploy log

Every host has a list of deployments, each with the commit id it built, a status, and a log. Open the log of the failed one and scroll to the first error, not the last line. Build tools print a wall of npm ERR! lines after the real problem, and the real problem is usually thirty lines above the bottom, saying something specific: a type error with a file and line, a missing module, a variable that is undefined.

Most build failures reproduce locally with npm run build. Run it before every push (the earlier lesson put it in the rules file), and the deploy log becomes something you read rarely.

Stamp the version

The lasting fix for “which version is live” is to make the running app say so. Hosts expose the commit id to the build as a variable: VERCEL_GIT_COMMIT_SHA on Vercel, CF_PAGES_COMMIT_SHA on Cloudflare Pages, COMMIT_REF on Netlify, RENDER_GIT_COMMIT on Render. Read it at build time and print the first seven characters in the footer, or serve it from a route:

TypeScript
// app/api/version/route.ts
export function GET() {
  return Response.json({ sha: (process.env.VERCEL_GIT_COMMIT_SHA ?? "dev").slice(0, 7) });
}

Now git log --oneline -1 on your machine and /api/version on the site can be compared, and “is my fix live” is a fact rather than a feeling. Add a started timestamp too, and the same route tells you whether the process restarted.

Caches

Modern builds give JavaScript files hashed names (main.a3f9c21.js), so a new build produces new filenames and browsers cannot serve stale code by accident. The HTML that references them can still be cached briefly by the browser or the CDN, which is the minute of lag after a deploy.

The exception is a progressive web app with a service worker. Service workers cache aggressively and serve the old version until the new worker has installed, which can take a reload or two. If an agent added PWA support because it seemed nice, this is the cost.

Rolling back

Because hosts keep every deployment, going back is a button: “promote to production” on an older deployment on Vercel, “publish deploy” on Netlify, “rollback” on Cloudflare Pages. It takes seconds and no rebuild.

What it does not roll back is the database. If the new version ran a migration, the old code now runs against a schema it has never seen, and may fail in a different way. That is the reason for the rule in the data block that migrations add columns first and remove them in a later release, once no live version still reads them. A rollback is only safe when the code before and the code after both understand the current tables.

Previews

Push a branch and most hosts build it to its own URL: app-git-payments-you.vercel.app or similar. Open that on your phone, send it to a friend, run the stranger’s checklist on it, all before anything reaches main. Preview deployments use the variables scoped to the preview environment, which is why the previous lesson insisted on a separate database for them.

Knowing it is still up

A health route is a page that returns quickly and says yes:

TypeScript
export function GET() {
  return Response.json({ ok: true, sha: process.env.VERCEL_GIT_COMMIT_SHA?.slice(0, 7) });
}

Free monitors (UptimeRobot and Better Stack both have free tiers) request it every few minutes and email you when it stops answering. That is a way to learn your site is down before a user does, and it costs nothing but the two minutes of setup.

Every lesson here is open. Your progress is recorded once you pass the Building with AI exam.

Check your understanding

You push a fix. The site still shows the bug. The host’s dashboard shows the newest deployment marked Failed. What is the site serving?

Pick the one you would defend. Your answer stays private.

Next lesson · 8 minA domain of your own

Stuck on something?Ask Beatriz, your AI tutor

How to cite: Addaly (2026) ‘Which version is live’, in Building Apps with AI. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/building-apps-with-ai/which-version-is-live (Accessed: 13 October 2026).