Vercel Deployment Stuck? Check the Git Commit Author

I run two GitHub accounts. One is for personal work, like this blog and my automation scripts. The other is for the services real customers use, such as WEAROOM and WECOSMO. I split them on purpose: it spreads the free-tier limits across two accounts and keeps the live services walled off from everything else I tinker with.

In the early hours of August 27, that split stopped a deployment cold. The change itself was small — a WEAROOM update that shows subscribers their current plan on the pricing page instead of sending them back to the card-registration screen. The code was pushed, and then the Vercel deployment simply sat there. It never reached the build step. Its status read UNKNOWN, and it stayed that way for close to ten hours.

The code was fine. The problem was the author name stamped on the commit. Once that was corrected and the commit pushed again, the deployment finished in 46 seconds. If you juggle two accounts, or you let an AI coding agent commit for you, you may be one setting away from the same thing, so here is the path it took.

A parcel paused at a gate because its name tag does not fit the slot — illustration made for this post

What actually happened

On my main work computer, most code changes and commits are made by an AI coding agent. When it commits, it signs the commit with whatever name and email Git is configured to use on that machine — exactly as Git would for a person typing the commands.

Git's author setting comes in two layers:

The global default — used by every repository that has not been told otherwise.

The per-repository setting — lives inside one repository's folder and overrides the global default when present.

I had recently moved to a new work computer. Its global default was my personal account, and the two service repositories had no per-repository setting yet. So the WEAROOM commit went out under my personal account's name, with no warning of any kind.

The commit worked. The push worked. The author name on a commit is separate from the login used to push, so Git has no reason to object when the two differ. The failure only showed up one step later, at deployment.

When there is no log, where do you look?

A failed deployment normally leaves a reason in the build log. This one left nothing. Asking Vercel for the deployment's details returned a single word: UNKNOWN. Not "failed," not "queued." Just unknown.

The clue was an asymmetry:

Redeploying an existing deployment worked. That reuses a build Vercel has already made.

Deploying the new commit did not.

If the build settings were broken, or Vercel itself was having a bad night, both would have failed. When only fresh commits get stuck, something about the fresh commit is different. Scrolling through the repository's history made it obvious: every earlier commit carried the service account's name, and this one alone carried the personal account's.

Vercel's own documentation describes the rule. For private repositories, Vercel checks the commit author against the team that owns the project. On a Hobby team, the commit author has to be the team's owner; on a Pro team, the author has to be a team member. The WEAROOM repository is private, and the deployment went through the moment the author was corrected, so this check is almost certainly what caught us. What surprised me is that our dashboard never said so. There was no message about the commit author, only that UNKNOWN status.

The fix: same code, different name

Not a single line of code changed. We rewrote only the author on the last commit, setting it to the service account, and pushed again. Because that means replacing a commit that was already on GitHub, we used a protected force push (force-with-lease), which refuses to overwrite anything if someone else has pushed in the meantime.

The original commit was made at 12:55 a.m. The author was corrected at 10:33 a.m. A deployment that had been frozen for nearly ten hours finished 46 seconds after the name was fixed.

Afterwards, both service repositories, WEAROOM and WECOSMO, got their own per-repository author setting. Whatever the computer's global default is, anything committed inside those folders now goes out under the service account.

The same root, a different symptom: "Repository not found"

Back in June we had the mirror image of this problem. Pulling the latest changes from one of my personal private repositories failed with "Repository not found." Yet on the same computer, GitHub's command-line tool could see the repository perfectly well.

The culprit was the Windows Credential Manager. At some point a login prompt had been approved with the service account, and from then on Git quietly reused that saved login whenever it talked to GitHub. GitHub, in turn, answers "not found" rather than "access denied" when an account without permission asks for a private repository — which makes a perfectly healthy repository look deleted.

The fix was to tell Git to use the account that GitHub's command-line tool is logged into (gh auth setup-git). We left the saved service-account login in place, since other tools still rely on it.

On the surface the two incidents look nothing alike. One froze a deployment; the other made a repository seem to vanish. Underneath, they are the same mistake: the computer does not know you have two accounts. It quietly uses whichever one it has stored.

Five checks if you work across two accounts

Pin the author per repository. Do not rely on the global default. In any repository that belongs to your other account, set git config user.name and user.email from inside that folder. The email must be one that is verified on that GitHub account.

Compare right before you commit. Check that the repository's configured author matches the author on its existing commits. A few lines of the commit log are enough.

If a deploy stalls with no log, check the author first. In particular, if redeploying an old build works but new commits get stuck, suspect the commit author before the code.

If a repository is "not found," check the account before assuming it was deleted. Private repositories answer "not found" to accounts without access. Find out which account Git is actually using.

Make it the first step on any new machine. This incident happened right after a move to a new computer. After cloning, do step 1 before you start working.

If an AI agent does your commits, there is one more point. The agent will not question the name your machine gives it. In my case, which repository belongs to which account had been written down in a table in my working-rules document since April — and the incident happened anyway. Knowing the table and checking that this particular repository's settings actually match it turned out to be two different things.

So the instruction file my agents read at the start of every session now says that checking the account before a commit is mandatory, and it spells out the setup order for a new machine: author settings in both service repositories first.

Closing thoughts

I still think splitting the accounts is the right call. But every split adds another place where things can quietly drift apart. I know which account a repository belongs to; the computer only knows the name written in its settings.

If you automate publishing, it is worth confirming results all the way to the public page — I wrote about that in An Automation Is Not Finished When It Saves. And for another way the same Vercel setup took our site down, see How Blog Images Took Our Vercel Site Down.