Hi Tilanddi,

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:

1
git show --name-only 412467a02250f14b7100f933b8f02eabb206108c
2

Then check the repo at that commit for either of these:

1
{
2
  "git": {
3
    "deploymentEnabled": false
4
  }
5
}
6

or a branch rule like:

1
{
2
  "git": {
3
    "deploymentEnabled": {
4
      "main": false
5
    }
6
  }
7
}
8

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.

Relevant config doc: https://vercel.com/docs/project-configuration/git-configuration

vercel.com

Git Configuration

Learn how to configure Git for your project through vercel.json or vercel.ts.

Hi,

Thanks for the pointers — I went through all of them. Here's what I found, ruling out each one:

1. 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.

2. Ignored Build Step: Set to "Automatic" (the default — skip only if the exact commit SHA was already deployed). Not customized.

3. Require Verified Commits: "Inherit from Team (Disabled)". Not the cause.

4. 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.

5. GitHub App installation: Active, not suspended, "Repository access" is set to "All repositories" (not restricted to a select list).

6. 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).

7. 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.

8. 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.

9. 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.

10. 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 your help digging further into this.

Hi Tilanddi,

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:

1
git grep -n '"github"\|"enabled"\|"deploymentEnabled"' -- vercel.json vercel.ts
2

Specifically look for this exact shape anywhere in vercel.json or vercel.ts:

1
{
2
  "github": {
3
    "enabled": false
4
  }
5
}
6

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: https://vercel.com/docs/deploy-hooks

vercel.com

Creating & Triggering Deploy Hooks

Learn how to create and trigger deploy hooks to integrate Vercel deployments with other systems.

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:

1
- one new commit SHA on main after reconnecting Git
2
- the Deploy Hook response job id, with the hook URL/token removed
3
- the branch selected for that hook
4
- confirmation that neither github.enabled nor git.deploymentEnabled is disabling deployments
5
- the approximate timestamp when the hook/push was triggered
6

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.