Pushes to main don't trigger any deployment on Hobby (not even failed/skipped)

Git pushes to main don’t trigger any deployment (Hobby plan)

Project: estas-bien-claude (Hobby plan)
Connected repo: albertoanibalmari-ship-it/estas-bien-claude on GitHub
Production domain: estas-bien-claude.vercel.app

The problem

Pushes to main stop triggering any new deployment — not a successful one, not a failed one, not even a “skipped” one. The Deployments list (checked with the “All Projects” filter too, not just this project) simply shows nothing after a certain point.

Last deployment that actually worked: ~2026-07-31 17:21 (-03:00), which roughly lines up with commit 8a1674c (2026-07-31 14:18:52 -03:00) or 09cf107 (2026-07-30 19:24:32 -03:00).

Three separate test commits pushed to main since then, none of which triggered anything:

SHA Timestamp (-03:00) Author email
eb77328 2026-08-02 03:36:57 albertoanibalmari@gmail.com
6d72025 2026-08-02 04:50:28 albertoanibalmari@gmail.com
3ecb071 2026-08-02 05:23:30 albertoanibalmari@gmail.com

What I’ve already ruled out

  1. Project-level Git connection (Settings → Git): repo shows correctly connected, including after a full Disconnect → Connect cycle done specifically to rule this out. deployment_status and repository_dispatch event toggles are enabled.
  2. Account-level GitHub connection (Account Settings → Authentication): found this was stale — showed “Last used Apr 16” (~4 months old). Disconnected and reconnected; now shows “Last used just now.” Pushed commit 3ecb071 after this reconnection specifically to test it — still nothing.
  3. GitHub App installation (checked on the GitHub side, Settings → Installations): correct permissions (Read+Write on code, deployments, commit statuses, checks, pull requests, repository hooks, workflows; Read on actions/metadata), repository access set to “All repositories” (not “Only select repositories”), not suspended.
  4. Domains: single domain (estas-bien-claude.vercel.app), “Valid Configuration,” assigned to Production. Only one project with this name on the account — no duplicate/stale project silently owning the domain.
  5. Ignored Build Step (Settings → Build and Deployment): set to “Automatic” (default) — shouldn’t skip a genuinely new commit SHA.
  6. Deployment Protection: only “Vercel Authentication” (Standard Protection, Require Log In) is on. As I understand it, this gates viewing deployments, not whether a build gets triggered.
  7. Commit author email: verified it matches a real, presumably-verified email on the connected GitHub account (albertoanibalmari@gmail.com, account albertoanibalmari-ship-it) — a support agent suggested this as a possible cause, but it didn’t turn out to be it, or reconnecting didn’t fix it either way.

What I need

At this point I’ve exhausted everything visible/actionable from the dashboard and from the GitHub side. Has anyone run into silent deploy-trigger failures like this before — webhook/event delivery issue on Vercel’s side that wouldn’t show up in any of the above? Any pointers on what else to check, or whether this needs a human to look at delivery logs on Vercel’s end, would be appreciated.

Follow-up: I checked repo Settings → Webhooks → Recent Deliveries as
suggested in a couple of related threads, and it’s completely empty —
no “Vercel” entry at all, broken or otherwise.

Worth noting for anyone else landing here with the same idea: I believe
this is actually expected, not a smoking gun. Our integration is via
the Vercel GitHub App (confirmed earlier in this thread — granular
permissions and “All repositories” access live under GitHub →
Settings → Installations, not under repo-level Webhooks). GitHub Apps
deliver events through a webhook registered once at the App level by
the app’s creator (Vercel), not a per-repo webhook — so nothing shows
up under repo Settings → Webhooks regardless of whether delivery is
working or not. Those delivery logs are only visible to Vercel, not to
us as installers.

So this doesn’t move the diagnosis forward on its own, but it does
confirm we’ve hit the ceiling of what’s inspectable from our side:
everything checkable from GitHub’s and Vercel’s dashboards looks
correct, and the only remaining unknown is what’s happening to the
push event once it reaches Vercel’s side of that App-level webhook.
That’s not something we can see — hoping someone from the Vercel team
can check delivery/processing logs for project estas-bien-claude
around the SHAs listed above.