The 404 in that webhook response is the real lead, not a side detail. When GitLab answers Vercel's fetch with 404 Not Found, it means the token Vercel is using cannot see the project it is trying to read, so the push lands but no deployment is ever created and nothing shows up in your deploy list.

A few things cause exactly this after a disconnect and reconnect:

1. Stale project mapping. Reconnecting rebinds gitCredentialId, but Vercel can still hold the old GitLab project id. Go to your GitLab repo, Settings, Webhooks, and look at the Vercel hook's Recent Deliveries right after you push. If GitLab shows the delivery failing, or there are two Vercel webhooks sitting there, delete them, then disconnect and reconnect from the Vercel side so a clean hook gets installed.

2. The token cannot see this specific project. Your other project works because it sits under a namespace your account fully owns. If the broken repo lives under a group, the authorized GitLab user or token may not have api access to that group, and GitLab returns 404 rather than 403. Reauthorize with the account that actually owns or maintains that project.

3. Confirm it is the trigger and not the build. From the Vercel dashboard, create a manual deployment or hit Redeploy on the last commit. If that builds fine, the problem is purely the GitLab to Vercel handoff, which keeps you focused on the webhook and token scope instead of your code.

The GitLab webhook Recent Deliveries view is the fastest signal here, since it tells you whether GitLab is even firing the hook and what response Vercel sends back.