Hello,
Project concerned: normivia (Project ID: prj_Uk10HtNzpK0IADgBeTJmIARx7zK4)
Connected GitHub repository: tilanddi-prog/Normivia (connected since July 8th)
Production environment: attached to the “main” branch, domain www.normivia.com
Problem
For several days now, commits pushed or merged to the “main” branch are no longer triggering any Vercel deployments, neither in Production nor in Preview — even though the GitHub integration appears correctly connected and the Production deployment is correctly attached to “main”.
This is what the GitHub status of the commit shows (via the commits/{sha}/status API):
context “Vercel” → state “failure”, description “Deployment failed.”
However, in the Deployments tab of the Vercel dashboard (all statuses displayed, including Error), no deployment corresponding to this commit appears at all. The "failure" status therefore seems orphaned—associated with no actual build attempt, rather than a true build failure.
Example of a recent commit involved: 412467a02250f14b7100f933b8f02eabb206108c (“Merge EPIC-V2-001: Reversible Archiving of an Organization”, 2026-08-08).
What I have already checked/tried (without lasting success):
Disconnected and then reconnected the project's GitHub integration (Project Settings → Git).
Checked "Ignored Build Step" (Build and Deployment): set to "Automatic," no custom build skip script.
Environments verified: Production correctly attached to “main”.
A Deploy Hook was manually triggered for “main”: this deployment worked and went to Production successfully. However, subsequent commits, pushed normally after this manual deployment, exhibited the same behavior (no automatic deployments triggered).
My request:
Could you investigate on the platform side why GitHub push events on “main” are no longer triggering builds for this project (blocked webhook, account limit, build queue stuck, or some other cause invisible to the dashboard)? The Deploy Hook workaround works but isn't sustainable for every merge—I need automatic triggering to be fully restored, not just a single deployment that turns green.
Thank you in advance.
Since the Deploy Hook can create a Production deployment, I’d first separate “Vercel can build the project” from “GitHub events are allowed to trigger deployments.”
A few non-sensitive checks I’d make:
git show --name-only 412467a02250f14b7100f933b8f02eabb206108c
Then check the repo at that commit for either of these:
git.deploymentEnabled can disable automatic Git deployments even if the GitHub app is still connected, so it’s worth ruling out separately from the dashboard “Ignored Build Step” setting.
I’d also check Project Settings → Git for “Require Verified Commits.” If that was enabled recently and the merge commit is not verified by GitHub, Vercel may reject the Git-triggered deployment path even though a Deploy Hook still works.
One more useful test: create a tiny new commit directly on main instead of reusing or fast-forwarding an already deployed SHA. If that new SHA also gets a GitHub Vercel failure but no Vercel deployment entry at all, that points more toward the Git integration / webhook processing path than the app build.
Thanks for the pointers — I went through all of them. Here’s what I found, ruling out each one:
vercel.json / git.deploymentEnabled: Checked both the current branch and the exact merge commit that’s live in Production (412467a02250f14b7100f933b8f02eabb206108c). No git key at all in vercel.json — no deploymentEnabled: false, no per-branch rule.
Ignored Build Step: Set to “Automatic” (the default — skip only if the exact commit SHA was already deployed). Not customized.
Require Verified Commits: “Inherit from Team (Disabled)”. Not the cause.
Classic repo webhook: None configured on the GitHub repo (Settings → Webhooks is empty) — confirms the integration relies entirely on the GitHub App, not a legacy webhook I could inspect delivery logs for myself.
GitHub App installation: Active, not suspended, “Repository access” is set to “All repositories” (not restricted to a select list).
Deploy Hook: Works at the API level — both the original hook and a freshly recreated one after reconnecting the Git integration returned a valid {"job":{"id":"...","state":"PENDING"}} response. Neither ever produced a visible entry in the Deployments list (checked all statuses, including Building/Queued/Error — nothing).
Project/team scope: Only one Vercel team (“Normivia”, Hobby plan) and only one project (“normivia”) exist on this account — ruled out a duplicate project or wrong scope receiving the deployments instead.
Git integration itself: I fully disconnected and reconnected the GitHub repository from Project Settings → Git. This did NOT restore automatic deployments — it did, however, invalidate the previously working Deploy Hook (had to recreate it), which is the only visible side effect.
Comparison with Railway (same GitHub repo, separate GitHub App installation, hosts our backend): Railway’s automatic deployments are working correctly and are up to date with the latest merge into main. This rules out an account-wide or GitHub-side permission issue — the GitHub side is fine, since a different app on the same repo/account deploys without issue.
Vercel status page: All systems operational, no ongoing incident.
Given all of the above, the remaining explanation seems to live in Vercel’s own webhook processing / deployment queueing on your end for this specific project. Could you check the delivery/processing logs on your side for recent push events from tilanddi-prog/Normivia (both main and EPIC-V2-001 branches) — I’d like to know whether the events are even reaching Vercel, and if so, why they’re not resulting in a deployment (silently dropped, erroring before a Deployment record is created, etc.)?
For reference, the last commit that WAS successfully deployed (via the GitHub integration) is 412467a02250f14b7100f933b8f02eabb206108c (Aug 8). Every commit since then, on both main and EPIC-V2-001, has produced no deployment at all — not even a failed/errored one.
Thanks for checking all of that. Just to clarify, I’m not Vercel staff, so I can’t inspect internal GitHub App delivery logs or deployment queue logs for the project from here.
One config check I’d still make is the legacy key, because it is separate from the newer git.deploymentEnabled setting:
Specifically look for this exact shape anywhere in vercel.json or vercel.ts:
{
"github": {
"enabled": false
}
}
That key is deprecated, but Vercel’s docs still describe it as disabling Vercel for GitHub deployments, and the Deploy Hooks docs mention that deploy hooks will not trigger when github.enabled = false is present:
If that key is not present either, I’d stop chasing normal build/app settings. A real build failure should usually create a deployment record with logs. A Deploy Hook returning PENDING but never creating any deployment entry points earlier than the build step.
At that point the most useful evidence for Vercel support/staff would be:
- one new commit SHA on main after reconnecting Git
- the Deploy Hook response job id, with the hook URL/token removed
- the branch selected for that hook
- confirmation that neither github.enabled nor git.deploymentEnabled is disabling deployments
- the approximate timestamp when the hook/push was triggered
Railway working on the same repo is a helpful comparison, but it does not fully prove the Vercel GitHub App path is healthy, since each GitHub App has its own installation and event handling. Given both Git pushes and Deploy Hooks are failing before a deployment record exists, this does sound support-facing once the legacy github.enabled check is ruled out.