I pushed a set of changes to a production site — new page sections, updated prerender content, a comparison table entry. Checked the live site an hour later. Nothing had changed.
Checked Vercel. Project showed healthy. No red deployments, no failure notifications, no emails. The dashboard looked completely normal.
Checked the Deployments tab. Last deployment: 10 hours ago. Not two minutes ago when I pushed. Ten hours.
Every commit had gone to GitHub fine — verified with git log, confirmed the remote had the latest SHA. Vercel simply hadn't picked any of them up.
What I ruled out first
GitHub webhook disconnected. Possible on any project if the GitHub app gets uninstalled or permissions change. But the Vercel project still showed the repo as connected. No indication of a broken webhook in settings.
Root directory misconfigured. There was a nested subfolder in the repo that had previously been used as the build root. That subfolder had been deleted. If Vercel was building from that path, every build would fail with a missing directory error. But the Root Directory setting showed ./ — the repo root. Ruled out.
Build command issue. Nothing had changed in package.json or vite.config.ts. The build had worked before.
Forcing a deploy to see the actual error
With the GitHub webhook not triggering, the only way to get a build log was to force a deploy manually. Used the Vercel CLI:
vercel --prod
Immediate error:
{
"status": "error",
"reason": "deploy_failed",
"message": "Redirect at index 0 cannot define both `permanent` and `statusCode` properties."
}
There it was.
The config conflict
In vercel.json, the first redirect — a www-to-non-www canonical redirect — had been written with both properties:
{
"source": "/(.*)",
"has": [{ "type": "host", "value": "www.yourdomain.com" }],
"destination": "https://yourdomain.com/$1",
"permanent": true,
"statusCode": 301
}
permanent: true and statusCode: 301 are redundant — permanent: true already means 301. Vercel's config validator rejects any redirect that specifies both. The fix is one line:
{
"source": "/(.*)",
"has": [{ "type": "host", "value": "www.yourdomain.com" }],
"destination": "https://yourdomain.com/$1",
"permanent": true
}
Why it was silent
This is the part worth documenting.
When a vercel.json config error fails validation, the GitHub webhook fires, Vercel receives it, validation fails before the build even starts, and the whole thing is discarded quietly. In this case, Vercel surfaced no visible failure notification in the dashboard or by email. The dashboard keeps showing the last successful deployment as if nothing happened.
The only visible sign is that the "Last deployment" timestamp stops advancing. If you're not actively checking that timestamp, you won't notice.
The failure was introduced with a commit that added statusCode: 301 to an existing redirect that already had permanent: true. The intent was clarity. The effect was silently breaking every deployment after it.
Secondary issue: CLI upload was stalling on node_modules
When I first ran vercel --prod to diagnose, the upload stalled at ~150MB and had to be killed. There was no .vercelignore in the repo, so the CLI was uploading node_modules (357MB) along with the source.
Fix:
# .vercelignore
node_modules
dist
.git
*.log
With that in place the upload dropped to ~39MB and completed in seconds.
What to check when Vercel stops auto-deploying
If pushes are going to GitHub but Vercel isn't deploying:
- Check the Deployments tab timestamp — if it stopped advancing, builds are failing before they start
-
Force a deploy via CLI (
vercel --prod) — the CLI surfaces the actual error immediately, the dashboard won't - Look at vercel.json first — config validation errors fail silently and are the most common cause of webhook builds being discarded without notification
-
Check for redundant redirect properties —
permanentandstatusCodeon the same redirect is the specific conflict Vercel rejects
The GitHub integration kept working. The pushes were fine. The config was wrong. Vercel's silence on the failure is the thing that made it hard to find.
Top comments (0)