Title: All deployments silently blocked on Hobby project since 7 Aug — even manual Deploy Hook produces zero deployment
Body:
Deployments on my project red-flag-ai-pro (Hobby plan) completely stopped around 06:58 on 7 August 2026. Last successful deployment is commit ae325b7. Every commit pushed since then (5+ commits) has not deployed.
What I’ve ruled out:
Not a bad commit — an empty diagnostic commit didn’t deploy either
Not a usage cap — well under all Hobby plan limits (Build Time 4h of 100h used)
Not an obvious Git disconnect — Project Settings > Git still shows the repo connected
No relevant email or dashboard banner about the account or project
The clearest evidence: I created a manual Deploy Hook and triggered it via curl. It returned a valid job response (job id zsC81CMjDuao1WDH78Ve, state PENDING), but no deployment — not even a failed one — ever appeared in the Deployments list.
I opened a support case but Hobby plan doesn’t get a ticket for CI/CD > Builds issues, only Community, so posting here. Has anyone seen this exact symptom (deploy hook accepts the job but never creates a deployment record) and found a fix? I’m not able to upgrade to Pro right now to get direct support.
Project: red-flag-ai-pro
Last working deployment: ae325b7 (7 Aug, 06:58)
Stuck deploy hook job ID: zsC81CMjDuao1WDH78Ve
I understand how frustrating this issue is, especially since you mentioned that you haven’t exceeded your usage limits and that your Git connection settings are correct.
This type of hold often occurs in hobby projects due to temporary security measures being activated on the account or project, or because the system detects a pattern it deems requires review. To try and resolve this issue, you can try the following:
Reconnect your Git repository: Go to Project Settings, then Git, disconnect from the repository, and then reconnect to refresh the deploy hooks synchronization.
Create a new manual deployment with a different URL or a new branch: Try pushing a very simple modification (such as changing a character in the Readme file) to a new branch or directly to see if the build system detects the event and responds.
Check your account logs: Make sure there are no pending notices or warnings in your main account settings requiring you to confirm some data or remove something that violates the terms of service. Since the amateur plan doesn’t allow opening direct support tickets, the best way to resolve this build system issue is to clearly state the problem here, including the pending task ID. The Vercel team or community moderators will often escalate the matter to the technical team to investigate why your Deploy Hooks are stuck.
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.
If a deployment fails before the build even starts, that would indicate it’s being rejected for some reason. The most common cause I’ve seen is a configuration issue.
You can test for configuration issues using the CLI to run vercel build or vercel deploy on your local repo. That’ll either succeed or output error details when it fails. Either way, that will give a clue about the source of the issue.
That makes me think it was a configuration or code change introduced after August 5. Can you look at your commits in GitHub or use the CLI to check for any error or success messages?
Thanks for the pointers — I went through all of them, plus one more test that I think is the actual lead: the Vercel CLI can’t authenticate against this account at all.
I generated a fresh Personal Access Token twice (from account/tokens), on two separate attempts, and every CLI command fails:
$ vercel whoami --token vcp_...
Error: User not found.
$ vercel teams ls --token vcp_...
Error: The token provided via `--token` argument is not valid. Please provide a valid token.
$ vercel project ls --token vcp_...
Error: User not found.
This is reproducible with a brand-new token each time, so it’s not a copy/paste issue. The dashboard (browser session auth) works fine for reading data, but anything going through token-based/API auth fails immediately with a user-resolution error. Given that GitHub-triggered deployments and Deploy Hook processing both happen server-side (and presumably need to resolve the account/user context too), I suspect this is the same underlying issue causing the deployment problem below — not a separate bug.
Here’s everything else I checked, 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). Not customized.
Require Verified Commits: “Inherit from Team (Disabled)”. Not the cause.
Classic repo webhook: None configured — the integration relies entirely on the GitHub App.
GitHub App installation: Active, not suspended, “Repository access” set to “All repositories”.
Deploy Hook: Accepted at the API level ({"job":{"id":"...","state":"PENDING"}}) both before and after recreating it, but never produced a visible entry in the Deployments list (checked all statuses).
Project/team scope: Only one team (“Normivia”, Hobby) and one project (“normivia”) exist on this account.
Git integration itself: Fully disconnected and reconnected — didn’t restore automatic deployments, only invalidated the previous Deploy Hook.
Comparison with Railway (same GitHub repo, separate GitHub App installation): deploys correctly and is up to date with the latest merge into main — rules out a GitHub-side/account-wide permission issue.
Vercel status page: All systems operational, no ongoing incident.
For reference, the last commit that WAS successfully deployed 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.
Could you check on your end why token-based auth resolves to “User not found” for this account, and whether that’s tied to the deployment issue?
Interesting. What version of the CLI are you using? Please try updating to the latest version of the CLI (currently 58.9.3), run vercel login (you might need to vercel logout first), and let me know if that works
Good news — this is resolved, and your suggestion is what got us there.
I updated the CLI to 58.9.3 and ran vercel logout / vercel login. The login itself went through fine (OAuth device flow), which immediately told me the earlier “User not found” / invalid-token errors were a separate, unrelated issue tied specifically to Personal Access Token generation — not connected to the deployment problem at all.
With the CLI properly authenticated, I ran vercel build then vercel deploy locally, and that’s where the real cause finally surfaced with an actual error message (something none of the GitHub-triggered attempts or Deploy Hook calls ever returned):
Hobby accounts are limited to daily cron jobs. This cron expression (0 * * * *)
would run more than once per day. Upgrade to the Pro plan to unlock all Cron
Jobs features on Vercel.
Our vercel.json had an hourly cron (0 * * * *, a health-check job) left over from before this limit apparently started being enforced on our Hobby plan. Every deployment attempt — GitHub push, Deploy Hook, all of it — was failing at this config-validation step, before a Deployment record was ever created. That’s exactly why nothing ever showed up in the Deployments list, not even as an error: the validation failure happened upstream of that.
I changed the cron to run once a day instead, redeployed via the CLI, and confirmed it went live on Production ([www.normivia.com](http://www.normivia.com)) successfully. Since the cause was a config validation issue rather than anything wrong with the GitHub integration itself, automatic deployments from future pushes should also work normally again now.
One piece of feedback, if useful: it’d have saved a lot of time if this same error had been surfaced somewhere in the dashboard (e.g. on the Deploy Hook response, or as a visible failed deployment) instead of only showing up via the CLI. Might be worth a look on your end for other Hobby-plan users hitting the same silent failure.
