Review a Preview deployment

A branch collects deployments. Every push to footer-year builds again, so after three commits the branch has three deployments. The branch URL follows the newest one. Each unique URL stays pinned to its own build.

That difference decides how you review. If you test the branch URL, you’re testing whatever was pushed last. If you test a unique URL, you’re testing one specific commit, and that commit is what you can approve.

Open the right deployment

Vercel posts the preview link on the pull request, and the dashboard lists every deployment for the branch. Open the one for the latest commit and confirm the SHA on the deployment page matches the pull request head:

git rev-parse --short origin/footer-year
# 4f2a9c1

If the deployment page says a different commit, you’re looking at an older build. Wait, or pick the right one.

Then test the changed paths, and a small set of things that should not have changed. For the footer change that means the home page, one note, and the create-note form.

Review the environment too

A visual check is not enough. Confirm the preview is using Preview credentials and test data, not production ones. The diagnostic page we’ll build in the environment variables lesson makes this a five-second check.

If the change touches a migration, a webhook, a scheduled task, or any third-party call, exercise that path on the preview. Those are the boundaries a screenshot approval doesn’t cover.

Leave evidence someone can repeat

Write the review so another person can rerun it. A good comment looks like this:

Reviewed 4f2a9c1 at https://field-notes-9k2m1x7de-flavio.vercel.app
Tested: /, /notes/first-note, /notes/new (created "review test")
Footer shows 2026. Health returns {"ok":true}.
Known difference from Production: uses the preview database.

Notice the unique URL, not the branch URL. If someone pushes again tomorrow, the branch alias moves, but this comment still points at the exact build that was approved.

And promote only what passed. If a new commit lands after your review, that’s a new deployment and it needs its own check.

Try this on your own project: push two more commits to the branch. Find the branch URL and both unique URLs in the dashboard, then write a short review comment tied to the latest commit, in the format above.