Five Subsystems, Sixteen Days: Vercel's July 2026 Incident Cluster, Counted

Between July 8 and July 23, 2026 — sixteen days — Vercel's status page recorded failures in five distinct subsystems: the build pipeline, SSO login, GitHub-linked deploys, the dashboard itself, and telemetry export. No single one was a catastrophe. Taken together, they are something more useful than a catastrophe: a measured sample of what the background failure rate of a shared, multi-tenant platform actually looks like once you stop counting headlines and start counting subsystems.

An earlier post on this blog covered the first two faults in that window — the build-pipeline incidents of July 8–10. This one covers what happened next: a SAML SSO outage on July 16, GitHub-linked deployment and login errors across July 16–17, dashboard and observability faults in the days after, and a six-minute Log Drains gap on July 23 that Vercel itself marked unrecoverable. The thread connecting them isn't a common cause. It's the opposite: there is no common cause, and that's the point.

The sixteen days, in one ledger​

Here is the full window, grouped into the five subsystem families that actually failed. Every entry below comes from Vercel's own status history and its mirrors:

Five families. Sixteen days. And note the shape: the failures don't cluster in one system that then gets fixed. They walk across the platform — builds, then identity, then the GitHub seam, then the dashboard, then the telemetry pipe. Each fix landed; each fix was for something different.

July 16–17: when both doors jam at once​

The middle of the window is the part worth slowing down for. On July 16, SAML SSO broke — a Major incident. For any team with SSO enforcement on (which is to say, most teams large enough to have compliance requirements), that is not a degraded-experience event. It is a locked door: no dashboard, no CLI, no deploys, no rollbacks, no log inspection. Your app keeps serving traffic, but you cannot touch it.

Within roughly a day, the second door jammed too: GitHub-linked deployments and authentication were affected across July 16–17. Even teams that don't use SSO felt this one, because the GitHub integration is the seam most Vercel deploys physically travel through — push to main, webhook fires, build starts. When that seam errors, git push stops meaning "deploy" and starts meaning "maybe, check the status page."

Two independent identity-and-trigger seams, failing within about 24 hours of each other, each one capable on its own of freezing a team's entire deploy loop. Neither touched production traffic. Both touched the thing teams actually do all day: ship. And because the SSO fault gates the dashboard while the GitHub fault gates the deploy path, a team hitting both had neither its normal workflow nor its normal fallback. The runbook for "can't deploy via GitHub" is "go do it from the dashboard" — unless the dashboard won't let you in either.

There is a sharper version of this for one specific population. Vercel has said that the share of its deployments triggered by coding agents rather than humans went from under 3% to more than half in about six months. An agent pushing code and hitting an auth error doesn't open a status page in another tab and wait it out. It reads the error as signal about its own diff, retries, re-authenticates, burns tokens and time debugging a door that isn't its door. Two jammed identity seams in 24 hours is a minor inconvenience for a human with the status page bookmarked. For an autonomous deploy loop, it's an unactionable failure wearing the costume of an actionable one.

Six minutes that are gone forever​

Then came July 23, and the incident this post is really about. Between 19:12 and 19:18 UTC, telemetry forwarded through Vercel's Drains was not delivered. The company's own wording is worth quoting exactly, because it draws a line most status pages blur:

Traces and events forwarded via Drains during this window were dropped and are unrecoverable.

Six minutes. Traces and events — gone, permanently, for every tenant whose observability pipeline hangs off a Drain. Not delayed, not backfilled (compare the July "Missing Build CPU Minutes" incident, where Vercel explicitly backfilled the data). Dropped.

There is a consolation in the same notice, and it deserves a fair reading: logs forwarded via Drains in that window were also not delivered, but they remain accessible in the Logs UI dashboard, where they can also be exported. So the failure had two halves with opposite outcomes — the copy Vercel keeps for you survived; the copy Vercel forwards to your own systems did not. Which half mattered more depends entirely on where your alerting, your SLO accounting, and your incident forensics actually live. If your Datadog or Axiom drain is your system of record — and for any team doing serious observability, it is, because dashboard retention is 1 hour on Hobby, 1 day on Pro, and 3 days on Enterprise — then the surviving dashboard copy is cold comfort. The data your monitors needed during those six minutes never arrived, and no retry will fetch it.

This is the unglamorous cost at the center of this story, so here it is plainly: a Drain is a third-party pipe between your app and your own telemetry, and a pipe can lose things in transit in a way a disk cannot. "Dropped and unrecoverable" is a failure mode that exists only because the bytes had to travel through infrastructure you don't operate on their way to infrastructure you do. Six minutes is short. The category is permanent — every future minute your telemetry spends in that pipe carries the same nonzero risk, and the status page has now shown you the exact sentence it will be described with.

Counting past the headlines​

Step back and count the way a tenant experiences it rather than the way a status page categorizes it. In sixteen days: builds you couldn't see the logs for, builds that failed for platform reasons, deploys paused by a phantom budget number, SSO doors locked, GitHub-triggered deploys erroring, Hobby functions failing invocations, dashboard logins erroring, dashboard charts timing out, and telemetry dropped in transit. That is roughly one tenant-visible fault every two days for over two weeks — across five subsystems, no two sharing a root cause.

No single row in that ledger is a scandal, and Vercel's handling reads as competent throughout: rollbacks were executed, the Drains fix shipped with a promise of additional monitoring, backfills happened where backfills were possible. This is what a normal incident rate looks like for a platform running over a million builds a day. That sentence is doing the real work in this post, so read it twice: normal. Not a bad month. Not an outlier. The ordinary background radiation of shared infrastructure at scale — each fault small, each fix prompt, each one landing on tenants who didn't choose the timing.

That's the number the headline-counting misses. Per-subsystem, Vercel's reliability looks like a row of green ninety-day badges with occasional amber. Tenant-experienced, it's the union across every subsystem your workflow touches — builds and auth and the GitHub seam and the dashboard and the telemetry pipe — and unions are always worse than their best member. The more of the platform your daily loop depends on, the more of its background rate you personally collect.

What changes when the pipe is yours​

None of this is an argument that Vercel runs bad infrastructure. It's an argument about failure domains — specifically, about which ones disappear when the platform runs on machines you own.

Take the Drains gap, since it's the sharpest row in the ledger. On a self-hosted platform where your apps and your observability stack run on the same reconciled fleet — provisioned by something like Cluster API on hardware you rent or own — there is no Drain in the architectural sense. Your runtime logs land on a disk your cluster controls; your forwarder (Promtail, Alloy, Vector, whatever you run) tails local files and ships to your own backend over your own network. That pipeline can absolutely break — misconfigured forwarders lose logs all the time. But it breaks as your bug, in your config, debuggable with your access, on a schedule correlated with changes you made. What it cannot do is take six minutes of your telemetry down with a failure in somebody else's forwarding control plane while your own systems report themselves healthy. "Dropped in transit through infrastructure I don't operate" is not a failure mode you can hit when you operate the transit.

The same collapse applies down the ledger. SSO failing platform-wide is replaced by your own identity provider failing only for you (and fixable by you). A GitHub-seam outage becomes a webhook receiver you can inspect, replay, and re-drive. Dashboard auth errors become your own console's bug, with your own logs to explain it. The honest trade-off, stated the way the earlier build-pipeline post stated it: you don't trade risk for safety, you trade a shared, invisible failure domain you can't inspect for a local, visible one you must staff. You own the pager. But you also own the logs that tell you why it went off — and nobody can mark them unrecoverable but you.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, where your build logs and runtime telemetry live on your own fleet instead of crossing a third-party pipe. Star the repo on GitHub or deploy your first app today.

Sources​

• Vercel Status — Incident History.
• Watchrr — Vercel status mirror (incident titles, severities, timestamps).
• IsDown — Vercel SAML SSO status (July 16, 2026 outage record).
• Vercel Docs: Log Drains.
• Vercel Docs: Runtime Logs retention.
• GitHub availability report: July 2026.
• Digital Applied: Vercel Ship 2026 — Agents Now Drive Half of Deployments.