[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Help](/c/help/9) # Next.js middleware fails to execute after Vercel CLI 50.28.0 build regression 249 views · 13 likes · 29 posts Garymast (@garymast) · 2026-03-06 · ♥ 1 ## Problem My `Next.js` `14.2.35` middleware stopped executing on production. After extensive debugging, I traced it to a regression in `Vercel CLI` `50.28.0`. ## Evidence I have two deployments of the exact same commit (`d14ff83`): * **Original build (`Vercel CLI` `50.27.1`)** → middleware works perfectly * **Fresh rebuild (`Vercel CLI` `50.28.0`)** → middleware never executes Both builds are identical — same `Next.js` version (`14.2.35`), same `ƒ Middleware 49.8 kB` in build output, same routes, same everything. The only difference is the `Vercel CLI` version. ## Symptoms * Middleware compiles successfully and appears in deployment summary under “Routing Middleware” with correct matcher * But it never executes at runtime — no headers set, no logs, no side effects * Middleware does **NOT** appear in the deployment **Functions** tab (no Edge function listed) * Even a minimal 5-line middleware (just sets one header, zero dependencies) doesn’t execute * Fails on both custom domains and `.vercel.app` URL * Clean redeploy without build cache doesn’t help * Tried `VERCEL_CLI_VERSION=50.27.1` env var but the version isn’t available on the registry **Middleware location:** `src/middleware.ts` (also tested at project root — same result) ## Workaround Promoting the old deployment built with CLI `50.27.1` restores functionality. ## Environment * **Framework:** `Next.js` `14.2.35` (App Router) * **Plan:** Hobby * **Structure:** `src/` directory Is this a known regression in CLI `50.28.0`? Is there a way to pin the build CLI version to `50.27.1`? Maya Avendaño (@mayven) · 2026-03-06 Hey @garymast, welcome to the community! Thanks for the detailed information, have passed this onto the CLI team to check out. GregUPP (@uponpro) · 2026-03-06 Same problems on my side. Seems that 50.28.0 broke something with the middleware. My multi-tenants app is not redirecting the users to their own sub-domains. Rocco Alt (@rocco-alt) · 2026-03-06 Same issue here. Next.js 15.5.12 with next-intl middleware (localePrefix: ‘as-needed’). All new deployments since March 6 ignore middleware.ts — unprefixed routes 404 while /en/\* works. Vercel AI support confirmed NEXT_ENABLE_ADAPTER is being injected by the platform, causing Next.js 16 proxy.ts behavior on a Next.js 15 project. Production site is down. Vercel CLI 50.28.0, Node 24.x. princhcanal (@princhcanal) · 2026-03-06 Same issue, but on `15.5.9` I’m getting this error from clerk ``` Clerk: auth() was called but Clerk can’t detect usage of clerkMiddleware(). Please ensure the following: Your Middleware exists at ./middleware.(ts|js) clerkMiddleware() is used in your Next.js Middleware. Your Middleware matcher is configured to match this route or page. If you are using the src directory, make sure the Middleware file is inside of it. For more details, see https://clerk.com/err/auth-middleware ``` Maya Avendaño (@mayven) · 2026-03-06 Thanks all, raising with relevant teams! Rcmisk 3732 (@rcmisk-3732) · 2026-03-06 same here! Nevo David (@nevo-david) · 2026-03-06 I just quickly migrated out of vercel, all production was down. I will monitor this, move back when it’s fixed Dimpurr (@dimpurr) · 2026-03-06 same here. all rewrites in middlewear not working Maya Avendaño (@mayven) · 2026-03-06 · ♥ 1 Thank you everyone for sharing, the team is actively looking into this - will post when I have further updates. Chen Jiaxing (@rcfans) · 2026-03-06 looks like I have this issue too. Jan Vorwerk (@slek) · 2026-03-06 I am not using the Vercel CLI… just pushing to GitHub… and observe that my middleware seems out of order in the recent deployments… The Vercel Help bot found that between my working deployments (yesterday) and today’s an env variable was added: VERCEL_SKIP_EDGE_FUNCTION_ENDPOINT No idea if it’s related or not… Chen Jiaxing (@rcfans) · 2026-03-06 Next.js Middleware fails on `Edge Runtime` but works with `runtime: 'nodejs'` on `Vercel`. I’m experiencing an issue where `Next.js` Middleware (`middleware.ts`) does not execute at all when deployed to `Vercel` using the default `Edge Runtime`. However, adding `export const runtime = 'nodejs'` makes it work correctly. ## Environment - **Framework:** `Next.js` `15.5.9` (`App Router`) - **Deployment:** `Vercel` (Production & Preview) - **Dependencies:** `@clerk/nextjs` `6.36.5`, but issue persists even with minimal middleware - **Local dev:** Works fine with `Edge Runtime` (`next dev`) ## Configuration ```tsx // middleware.ts (Edge - NOT working on Vercel) import { clerkMiddleware } from '@clerk/nextjs/server' export default clerkMiddleware() export const config = { matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'], } ``` ```tsx // middleware.ts (Node.js - WORKING on Vercel) export const runtime = 'nodejs' // Adding this fixes it import { clerkMiddleware } from '@clerk/nextjs/server' export default clerkMiddleware() ``` ## Observed Behavior - **With default Edge Runtime:** Middleware never executes (no logs in `Vercel` Function Logs). - **Error:** `auth()` throws: > **"can’t detect usage of clerkMiddleware()"** (because the middleware chain is broken). - **With `runtime = 'nodejs'`:** Middleware executes correctly on every matched request. ## Steps Tried 1. Simplified matcher to catch-all patterns 2. Cleared `Vercel` build cache & redeployed 3. Upgraded to latest `Next.js` and `@clerk/nextjs` versions 4. Verified file location (`src/middleware.ts` at project root level) ## Expected Behavior `Edge Runtime` should work as documented for Middleware, or documentation should clarify when `Node.js` runtime is required. ## Additional Context Issue appears specific to `Vercel` build environment; local `next dev` works fine with `Edge Runtime`. Maya Avendaño (@mayven) · 2026-03-06 · ♥ 1 Team is actively investigating, status page here: https://www.vercel-status.com/incidents/963t8qqbk77b Edit: incident resolved. João Narciso (@jotanarciso) · 2026-03-06 Same here. Chen Jiaxing (@rcfans) · 2026-03-06 The issue is not about CLI 50.28.0. This deployment work fine, pls check the log. ``` Running build in Washington, D.C., USA (East) – iad1 Build machine configuration: 2 cores, 8 GB Cloning github.com/RCFans/StrategyLogic (Branch: main, Commit: 8a6fc5f) Cloning completed: 1.806s Restored build cache from previous deployment (DQrH1rmBSHDcQhpyaYjNHWWAEPRd) Running "vercel build" Vercel CLI 50.28.0 Detected `pnpm-lock.yaml` 9 which may be generated by pnpm@9.x or pnpm@10.x Using pnpm@9.x based on project creation date ``` deployment link is below, if you can visit. [https://vercel.com/strategylogic/platform/4kzdVAaqeMz4cs7tWMD414fsGnAh](https://vercel.com/strategylogic/platform/4kzdVAaqeMz4cs7tWMD414fsGnAh) Dalyan Parker (@dalyan-6377) · 2026-03-06 · ♥ 2 Same here, this is is crashing our site. I was able to promote a previous deployment from a few hours ago and that has at least brought the site back up. Strangely, that deployment also use CLI 50.28.0 about 5 hours ago and succeeded. Everything after that suffered the issue discussed here - no middleware invocation whatsoever. Also for future reference, I checked the Vercel status page frequently over the past hour and there was no mention of this - would have been nice to at least have some mention of an investigation instead of me debugging alone, diagnosing the issue, then doing a general search to find this community thread. Pauline P. Narvas (@pawlean) · 2026-03-06 · ♥ 2 [quote="Dalyan Parker, post:24, topic:35534, username:dalyan-6377"] Also for future reference, I checked the Vercel status page frequently over the past hour and there was no mention of this - would have been nice to at least have some mention of an investigation instead of me debugging alone, diagnosing the issue, then doing a general search to find this community thread. [/quote] Welcome to the community, feel free to make posts in the future so you don't have to debug alone :slight_smile: But yeah, heard. Appreciate the feedback, Dalyan! :folded_hands: João Narciso (@jotanarciso) · 2026-03-06 Rollback has resolved the issue for now. Pauline P. Narvas (@pawlean) · 2026-03-06 · ♥ 1 We recommend redeploying, more to follow. Appreciate your patience everyone! Maya Avendaño (@mayven) · 2026-03-06 · ♥ 1 I hear you, it's under the same issues that's affecting middleware, as mentioned in the status page [here](https://www.vercel-status.com/incidents/963t8qqbk77b) ilia (@ilionic) · 2026-03-06 Spent most of my day debugging issues related to critical redirects defined in the middleware (and project experiencing severe downtime) While periodically checking Vercel Status page.. It would be REALY helpful to proactively report and monitor such kind of issues… 4+ hours delay in status update is unacceptable for such critical problem Dvass (@dvass88) · 2026-03-07 · ♥ 1 We hit the same issue. Two changes fixed it immediately: 1. Set `runtime: "nodejs"` in the middleware config (instead of Edge Runtime) 2. Pin Node.js to `22.x` via `engines.node` in `package.json` No rollback needed, new deployments work fine with these changes. Linkie Link (@tim-9762) · 2026-03-07 I spent the last two days debugging as well, even tried rewriting a huge part of our app, but had no luck so far. We’re not even using a middleware on the app; however, some pages are unusable now (still) because they keep re-rendering and reloading. We rolled back to a working deployment from Mar 4, 2026, 4:39:11 PM UTC. All following deployments (even of the same codebase). The older deployments don’t show any Vercel CLI info. So I can’t confirm whether Vercel CLI is working. I see the middleware incident marked as resolved. Is the team still investigating these kind of issues? We use Next.js 16.1.6 with: ``` skipTrailingSlashRedirect: true, trailingSlash: false, reactCompiler: true, cacheComponents: true ``` Kieran M (@kieranmcguire) · 2026-03-09 @mayven there’s a mistake in the email sent to customers about this incident. The email body implies that the issue spanned the period between 11:20 UTC to 18:34 UTC on March 6, 2026, but the link to the filtered list of affected deployments spans 11:20 UTC on March 5 to 18:34 UTC on March 6. Not sure which is correct. Maya Avendaño (@mayven) · 2026-03-09 Thank you for the feedback, I hear you. From the first post in this community thread it was raised internally within 30 minutes, and escalated as an incident as we saw folks in this thread sharing they were also having issues. We then had the first status page up within that hour, whilst the team were investigating. Myself and @pawlean were actively monitoring the situation as the team were working hard on finding the root cause and fixing, and we relayed relevant information here as soon as we knew more. I appreciate it's frustrating when these things happen, but I can assure you we all want to get accurate, up to date information out to everyone when it does happen, and we are always wanting to improve. We appreciate your understanding and patience. And thanks to our community, the issue was on our radar sooner! 🙏 Maya Avendaño (@mayven) · 2026-03-09 · ♥ 1 Hey @kieranmcguire, welcome to the community! Thanks for flagging, I've passed this to the team. Maya Avendaño (@mayven) · 2026-03-09 Hey @tim-9762, welcome to the community :slight_smile: Deployments without middleware shouldn't have been affected by this, so this could be a different issue, hard to say without more information. Can you open a new post in #help with [more details on the issue](https://community.vercel.com/t/how-to-get-good-answers/158?u=mayari)? Matt Valitski (@valitskim) · 2026-03-09 · ♥ 2 Hey Tim, Im on the team supporting Helius from the Vercel Side. Shoot me an email and I can see how we can help! Matthew.valitski@vercel.com