Deployments not being created despite successful trigger requests (project stuck since ~2026-07-22)

Help
1

Subject: Deployments not being created despite successful trigger requests (project stuck since ~2026-07-22)

Project: groovequake
Project ID: prj_YkSVRZPm7aTyBiWY5WCMxiBVSuzA
Account: Hobby plan

Issue: No new deployment has been created for this project since commit 98a7734 (~3+ hours ago), despite multiple confirmed-successful trigger attempts through three independent paths. Each attempt returns a clean 201 response with a new job in PENDING state, but none of these jobs ever produce a visible deployment in the dashboard.

What I’ve verified is NOT the cause:

Git repository connection: disconnected and reconnected lbohler/groovequake in Project Settings → Git — no change.
GitHub App permissions: Vercel’s GitHub App installation has explicit “Only select repositories” access to lbohler/groovequake, with read/write access to deployments, repository hooks, commit statuses, etc.
Domain: groovequake.fm shows “Valid Configuration” under Production on this exact project.
Deployment status filters: confirmed all 7 statuses (Ready, Error, Building, Queued, Initializing, Canceled, Blocked) are checked in the Deployments view — nothing hidden.
Account usage/billing: no quota-exceeded or payment-failure banner visible on the Usage page.
Direct evidence of the problem — three separate job IDs stuck in PENDING, never resulting in a deployment:

gkw0c7zM8XWMGbfNtF4A — triggered via direct curl POST to the project’s deploy hook URL
Ep06jZsXpf2t5HGzeiQg — triggered via GitHub webhook ping event
0CxbTWqpDkiGQU2R32PX — triggered via GitHub webhook push event (real push to main, commit b853551)
All three requests hit https://api.vercel.com/v1/integrations/deploy/prj_YkSVRZPm7aTyBiWY5WCMxiBVSuzA/2AbtPgmBS2 and got a clean 201 with {“job”:{“id”:“…”,“state”:“PENDING”,“createdAt”:…}}. None of these jobs ever appear as a deployment in the project’s Deployments list, regardless of status filter.

I also pushed two ordinary commits directly to main via the standard Git integration (commits 46a1464 and b853551) in between these tests — neither produced a deployment either, confirming this isn’t specific to the deploy-hook path.

Ask: Can you look up what’s happening to these job IDs internally? They’re being accepted and queued but appear to be stuck or silently dropped before ever becoming a deployment.

2

Update — found the root cause, closing this out.

It wasn’t a Vercel platform bug — it was self-inflicted. My vercel.json had a cron job registered at */15 * * * * (every 15 minutes), and Hobby accounts only allow cron schedules that run once per day. That validation failure was rejecting every deployment before a deployment record was ever created, which is why nothing showed up anywhere in the dashboard — not as an error, not in any status filter, nothing to point to. The CLI (vercel --prod) was the only thing that actually surfaced the real error message:

Hobby accounts are limited to daily cron jobs. This cron expression (*/15 * * * *) would run more than once per day. Upgrade to the Pro plan to unlock all Cron Jobs features on Vercel.

Fix: removed that cron entry from vercel.json and moved it to an external trigger (cron-job.org hitting the route directly every 15 minutes with a bearer-token header) instead of Vercel’s native cron. Deployments started working again immediately on the next push — no other config changes were needed.

One suggestion for the Vercel team: it’d save a lot of debugging time if this specific failure mode surfaced somewhere in the dashboard — even a “Blocked” or “Error” status deployment with this message attached — rather than only being visible via the CLI. Every dashboard signal (Git connection, GitHub App permissions, domain config, deploy hook responses, even a manually-added GitHub webhook hitting the deploy hook directly) looked completely healthy the whole time, because the request was being accepted (201, job PENDING) and only rejected during the actual build step.

Thanks to whoever picks this up — hopefully saves the next person some hours.