Vercel's Builds component broke for 30 minutes on 28 September 2026. If you built or deployed a function using Edge runtime in a narrow window, the fault was on Vercel's side, not yours.
Started
13:44 UTC
Duration
Lasted 30m
Source
IsDown
Next time
Vercel is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Builds
What happened?
Vercel posted a single incident for this day, starting at 13:44 UTC and resolved by 14:11 UTC, a total of 30 minutes. The incident affected one component: Builds. Vercel's own first update narrowed the trigger further, saying a small number of customers who built or deployed functions using Edge runtime between 13:01 and 13:11 UTC saw elevated rates of build failures due to an unexpected error. The same update noted that some builds actually succeeded but then returned 500 errors when the deployed function ran on Edge runtime. Vercel's advice at the time was to re-deploy functions using Edge runtime to accelerate remediation, which tells you this was treated as a transient fault rather than a configuration problem on your end. The second and final update, at 14:11 UTC, simply marked the incident resolved with no further detail on root cause. No breakdown of what caused the unexpected error has been published. No user reports were filed during this window, so the practical reach of the fault is hard to size beyond what Vercel itself described as a small number of customers. Vercel's 90 day history shows 27 incidents with a median duration of 1 hour 36 minutes, so this one resolved faster than typical. Across all time Vercel has logged 543 incidents, averaging 8.6 per month, which gives useful context for how often build and runtime issues surface on this platform.
Learning
UptimeRobot's own probes for Vercel's api component, run from EU and NA regions every 60 seconds, show 100% uptime across the last 24 hours, 7 days and 30 days, and this incident was not registered against those probes. That is not a contradiction. Edge runtime build failures happen at the build and deploy pipeline layer, not at the live api endpoint that external checks poll, so a clean uptime record for api can sit alongside a real, Vercel-confirmed failure in Builds. This is the general shape of the failure to watch for on platforms like this one: the part you can ping from outside stays healthy while the part that turns your code into a running function breaks quietly behind it. Watching your own deployed endpoints would have told you a deploy failed, at best, not why, and would have told you nothing about functions that built fine but then threw 500s at runtime. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
