Inspect the first deployment

The dashboard says Ready. That’s the moment most people stop. I want you to keep going, because Ready only means the build finished. It doesn’t mean the app works.

Every deployment records what was built, how, and where it lives. Open the deployment page and you’ll find the commit SHA, the branch, the environment, the build duration, the framework Vercel detected, the full build log, and the list of domains attached to it.

Read the build log once from top to bottom. You’ll see the install step, the next build output with the route table, and the upload of the output. Later, when a build fails, you’ll know what a healthy one looks like.

Save the unique URL, not just the alias

Each deployment has a URL that is its own forever, something like https://field-notes-9k2m1x7de-flavio.vercel.app. The production alias field-notes.vercel.app points there too, for now.

Write down the unique URL and the deployment ID. The alias moves with the next release. The unique URL doesn’t, so it’s the only address that lets you come back and inspect the exact artifact you tested today.

Test with the browser and with curl

Open the deployment URL and click around. Then do the same from the terminal, because a browser hides status codes, redirects and headers:

curl -sI https://field-notes-9k2m1x7de-flavio.vercel.app/notes/first-note | head -5

You should see a 200, a content-type: text/html, and a cache header. Try a route that doesn’t exist:

curl -sI https://field-notes-9k2m1x7de-flavio.vercel.app/notes/does-not-exist | head -1
# HTTP/2 404

And the health route:

curl -s https://field-notes-9k2m1x7de-flavio.vercel.app/api/health
# {"ok":true}

Cover a static page, a dynamic page, a form submission, a missing resource, and the health check. Those five requests exercise the paths a green build says nothing about.

When the build is green but a page fails

A 500 on the deployed app, when it worked locally, is almost never a build problem. Don’t rebuild the same commit hoping it changes. Open the runtime logs for that deployment, find the request, and read the error. We’ll spend a whole lesson on this later.

Try this on your own project: from the deployment URL, test the home page, one note URL, a missing note, and /api/health. Note every difference from what you saw locally, even small ones like a header that changed.