Vercel deployment failure with internal error during deploying outputs phase

Help
, ,
138

Hi there,

Thank you for your patience while we investigated this. As the dxb1 (Dubai) region is still unhealthy, and we’ve deployed a mitigation to address the elevated build errors. As part of this temporary measure, builds that use Middleware or Edge Functions will exclude dxb1 from their deployment targets. You can redeploy to test this.

If you’re still seeing failures, especially with Edge Function deployments, please switch the function to the Node runtime. With the Node runtime, the function will deploy only to your project’s Functions Regions rather than all Edge regions, which avoids the impacted Dubai Edge region during this incident. Using the Node.js Runtime with Vercel Functions

We are now working on a mitigation for Builds that are using Edge Functions. However the above workaround should unblock you immediately.

Please let us know if you continue to see errors after applying this change. Happy to help with any questions.

4 Likes
139

I am experiencing a persistent deployment failure with my project after attempting to change the deployment region. I have followed all the standard troubleshooting steps, but the issue remains unresolved.

140

Same on my side, iad1 issue:

Running build in Washington, D.C., USA (East) – iad1

141

Same issue. Even after updating regions in vercel.json its still failed 4-5 times. Is there any timeline on this issue fix. Asking to push fixes from users instead of doing somewhere in a generic fashion by the Vercel staff is a hilarious RCA fix

142

Your deployment is still using edge function which are affected:

image
image2376×172 35.8 KB

You can consider swiching to node runtime Using the Node.js Runtime with Vercel Functions until we rollout the fix for edge functions

1 Like
144

Yes you can switch to Node runtime to unblock immediately, you can do this by removing export const runtime = 'edge'; from your function

1 Like
145

I saw the Vercel Staff recommendation to switch Middleware from Edge to Node.js runtime as a workaround. Before I make that change, I have a billing concern:

Our middleware currently runs on the Edge runtime, which is included in the Pro plan. If I switch to the Node.js runtime (nodeMiddleware: true in next.config), will this start incurring Vercel Functions usage charges separately?

Our middleware handles every request (multi-tenant routing, subdomain detection, cookie injection), so the invocation count would be significant. I want to make sure this temporary workaround won’t result in unexpected charges.

146

Nice to see a BR in the loop! Valeu Diogo! Tried it out here but in my case, even with the regions explicitly set, it only worked after I checked for any files using edge runtime. I had two files set to edge, and switching them back to nodejs as @swarnava suggested finally allowed the deploy to bypass incident. If anyone is still stuck, double check your runtimes!

1 Like
147

No luck after changing the region and runtime.

However, I managed to fix it by simply renaming middleware.ts to proxy.ts and renaming the middleware() func to proxy()

1 Like
148

I have the same issue for Running build in Washington, D.C., USA (East) – iad1

it is not resolved for me after the new update at Mar 02, 2026 - 13:00 UTC

2 Likes
149

There’s no billing difference between Edge and Node.js runtime for middleware. Both are now part of the unified Vercel Functions infrastructure with consistent pricing based on Active CPU time.

The key points:

  • Edge Middleware has been unified — It’s now called “Vercel Routing Middleware” and runs on the same Vercel Functions infrastructure regardless of whether you use the Edge or Node.js runtime

  • Same pricing model — Both runtimes use Active CPU pricing, so switching to nodeMiddleware: true won’t introduce a different billing structure

  • Pro plan includes 10M Edge Requests — Your invocations count against this allowance either way

Since you’re already running middleware on every request with the Edge runtime, you’re already being billed under this unified model. Switching to Node.js runtime won’t suddenly add new charges.

You should be safe to make the switch as a workaround for the current Dubai region incident without worrying about unexpected billing surprises. Otherwise, if you can afford to wait, we are working on mitigating Edge function as well.

1 Like
150

just add the following to your edge functions: (NOTE: you had to add it to each as Next.js doesn’t support re-exporting config values from another file…

export const runtime = "edge";
// Exclude dxb1 (Dubai) - Vercel outage workaround
export const preferredRegion = [
  "arn1",
  "bom1",
  "cdg1",
  "cle1",
  "cpt1",
  "fra1",
  "gru1",
  "hkg1",
  "hnd1",
  "iad1",
  "icn1",
  "kix1",
  "lhr1",
  "pdx1",
  "sfo1",
  "sin1",
  "syd1",
  "yul1",
];
151

Same error, it still continues

152

Same issue with the region:
Region: Washington, D.C., USA (East) - us-east-1 - iad1

1 Like
153

AWS Dubai is down, that’s the reason why the deploy is not working.

https://www.reuters.com/world/middle-east/amazon-cloud-unit-flags-issues-bahrain-uae-data-centers-amid-iran-strikes-2026-03-02/

1 Like
154

same issue. changing region and redeploying still takes iad1.

1 Like
155

This is unacceptable, guys. We are losing a day of work with critical patches we can’t apply to prod. Switching to Node.js has a real impact on latency. from 5ms to 100 ms-200 ms on some clients.

156

The same proble here in Brazil gru1

157

Changed to node runtime and also changed the regions, but deployment still fails.
When will it be fixed?

158

still fails with every deployment