Starting with the conclusion

When production is deployed straight from the Vercel CLI with vercel --prod instead of GitHub integration, the deployment is never linked to a git commit. If two people run vercel --prod at the same time, the later one silently overwrites the other — and checking vercel inspect afterward gives you no way to tell which build (and which commit) is actually live.

Symptom

On the morning of 2026-09-16, two separate pieces of work ran vercel --prod against the same Vercel project at the same time, colliding three times.

This project's deployment isn't triggered by a GitHub push integration — it's a local vercel --prod that uploads a build directly. That means every deploy reaches production instantly without anyone having to think about git state. The tradeoff: Vercel is never told which commit the build came from in the first place.

Running vercel inspect against the production deployment confirms this: the output lists the deployment ID, project name, state, creation time, the set of aliases, and the build artifacts — nothing resembling a git commit hash or commit message. This isn't a one-off rendering glitch from that incident; checking a CLI-uploaded deployment today still shows nothing about which commit it came from.

So when the two builds collided three times, there was no way afterward to look at vercel inspect and work out "which change is live right now." We couldn't even safely assume our own change had landed. The only way to re-establish certainty was to redeploy from the latest commit on the main branch, which meant two redeploys that shouldn't have been necessary.

Cause

The root cause: choosing a CLI-upload workflow instead of GitHub integration means the mechanism that ties a deployment to a git commit simply doesn't exist.

A GitHub-integrated deployment is built in response to a detected push, so Vercel can always record which commit it came from. A CLI upload, by contrast, is just a channel for sending a local build artifact — there's no standard way for it to tell Vercel which commit's working tree produced that artifact.

Because this project uses the CLI-upload workflow, Vercel had no material to distinguish between concurrent deploys from the start. Last-write-wins overwriting can happen with ordinary deployments too, but with GitHub integration the commit record lets you confirm which one is live now. With CLI upload, that information never existed, so there's no way to check it after the fact — that's the real difference.

Fix

To fix this without switching integration methods or touching the CLI workflow, we made no code change. Instead we wrote down an operational step: before running a deploy, confirm no other work is about to deploy at the same time.

Following that check on every deploy prevents the situation where two vercel --prod runs happen at once in the first place. Rather than trying to make vercel inspect distinguishable after the fact, we're preventing the collision before it happens.

Prevention

This incident caused no harm to production customers. Both of the colliding runs were from the same person (the same operator), so it resolved with two extra redeploys to re-establish certainty.

If you choose CLI-upload deployment over GitHub integration, you need to go in knowing that the assumption "I can check git state after deploying" does not hold. This isn't a Vercel bug — it's a capability that never existed once you picked that integration method, and it can't be solved by adding an after-the-fact check. The only real fix is eliminating the possibility of a concurrent run before it happens.

Originally published at tech.rebounder.jp.