Three PaaSes, Ten Days, Nine Incidents: What Vercel, Fly.io, and Render's July 2026 Status Pages Show Side by Side

Between July 17 and July 27, 2026 — ten days apart — Vercel, Fly.io, and Render posted nine incidents to their status pages. Vercel lost dashboard authentication and dropped telemetry unrecoverably on the same day. Fly.io's Machines API returned 5XXs worldwide because a single token-validation host failed to reboot. Render's dashboard and REST API degraded with timeouts, with deploy failure reasons switched off as a mitigation. Three unrelated hosted platforms, three separate failure modes, one ten-day window.

That clustering invites an obvious question: is this what concentrated-cloud risk looks like, or just coincidence with a narrative wrapped around it? I read all nine incident reports side by side, plus the one genuine root-cause postmortem in the bunch and GitHub's July availability report for context. Here is the timeline, what each outage actually was, and the honest verdict on shared versus independent failure.

The timeline: nine incidents in ten days​

Counting rule, stated up front: every incident posted to vercel-status.com, status.flyio.net, or status.render.com with a created date from July 17 through July 27, 2026. Nine entries.

Two patterns jump out before any analysis. First, the control plane took most of the damage: dashboards, APIs, deploys, and telemetry account for six of the nine rows, while running workloads were explicitly unaffected in the worst-looking one (Fly.io's). The exceptions prove the shape — Hobby function invocations failing, Oregon services unreachable, and the Community site going down are the three rows where something other than the control plane broke. Second, July 23 was Vercel's bad day all by itself — three separate incidents, two in the morning UTC and a data-loss event in the evening.

What each outage actually was​

Vercel: a triple-incident day and unrecoverable telemetry loss​

Vercel's July 17 incident was narrow but instructive: only Hobby-plan teams, only new deployments created inside a four-hour window, and the prescribed fix was to redeploy or roll back. That shape — a bad build or config that only affects artifacts created while it is live — is the classic deployment-pipeline failure, and scoping the blast radius to Hobby suggests a staged rollout that never reached paid tiers. Annoying for exactly the users least able to page anyone, but contained.

July 23 was the real story. The morning brought two overlapping dashboard incidents: authentication errors that made the dashboard inaccessible for some users (Vercel rated it critical), and timeouts loading charts and observability data across six surfaces — Firewall, Observability, Sandboxes, Speed Insights, Web Analytics, and Workflows. Then, that evening, the week's most consequential six minutes: between 19:12 and 19:18 UTC, telemetry forwarded through Drains was not delivered. Vercel's own words: traces and events "were dropped and are unrecoverable." Logs fared better — still queryable and exportable from the Logs UI — but any team piping traces to an external observability backend through Drains has a permanent six-minute hole.

Of the nine incidents, this is the only one where the word "unrecoverable" appears, and it is doing a lot of work: every other row on this list is about availability, while this one is about data loss.

July 25 added a minor coda — the Vercel Community site briefly unavailable — which matters only as a reminder that "the platform" includes surfaces far from production traffic.

Notably absent from all five Vercel entries: root causes. Each report describes impact, timeline, and resolution ("a fix has been implemented"), but none says what broke or why. That is standard status-page practice, not a cover-up — but it puts a ceiling on what side-by-side reading can conclude, a point worth returning to.

Fly.io: the only true postmortem in the bunch​

Fly.io's July 20 incident looked the scariest on paper — "high number of 5XX on the Machines API and dashboard," rated critical, worldwide — and turned out to be the best-documented. The status page identified the trigger within forty minutes: an internal authentication service for the Machines API had failed, while existing Machines and apps kept running normally. Then Fly's infra-log, which the company describes as aiming for "100% fidelity to internal incidents," published the full root cause.

The host running the primary node of tkdb, Fly's token-validation service, went offline for maintenance and failed to reboot because of a separate hardware issue. Token validation timed out, and everything downstream of authentication — Machines API, flyctl, dashboard operations — failed with it. API and dashboard functionality recovered within minutes once the host was restored to service.

The interesting part is what Fly admitted next. The contributing factor, in their telling, is that tkdb is single-primary — and unlike its sibling service petsem (which powers app secrets and TLS certificates), tkdb read replicas cannot function while the primary is entirely offline, because replicas must receive revocation notifications to uphold token security guarantees. Fly is now investigating how to relax that requirement without weakening those guarantees. That is a genuine architectural trade-off disclosed in public: a security property (prompt revocation) purchased with an availability risk (no primary, no validation), which a routine maintenance reboot plus bad hardware luck then collected on.

The same incident also degraded some Managed Postgres v1 clusters — v2 was unaffected — a detail that hints at shared internal dependencies without spelling them out. And Fly's community team later summarized the day bluntly: "The Machines API went down for an hour worldwide on July 20, due to a failure of the tokens service's primary node." One hour of control-plane outage, zero workload impact, full public root cause. Every platform should write postmortems like this.

Render: dashboard, API, and an unnamed upstream provider​

Render's July 20 entry — degraded builds and deploys in all regions — is the thinnest report of the nine, essentially a title and a resolution. The July 24 Oregon disruption is more revealing: a critical, region-wide event where "some services may be unreachable or experience failed requests," which Render attributed to "an upstream provider." Which provider, and what failed, went unstated. For a platform whose regions sit atop someone else's physical infrastructure, "upstream provider" is doing the same quiet work as Vercel's "a fix has been implemented" — it localizes the blame without illuminating the cause.

July 27 was Render's longest incident of the window. What started as slow dashboard requests expanded the same afternoon to the REST API: degraded performance, timeouts, "you may need to retry your request." The mitigation is the telling detail — Render temporarily disabled deploy failure reasons (while still generating the underlying events) to shed load, and only re-enabled them the next day after observing no further issues. That is a textbook graceful-degradation move, and Render narrated it clearly across seven status updates spanning 29 hours. Nobody's data was lost and nothing went unreachable; the cost was a day of slowness, retries, and reduced deploy diagnostics.

The verdict: independent failures, shared dependencies one layer down​

So: concentrated-cloud risk, or coincidence? Reading all nine reports, the honest answer is mostly the latter — with the genuinely interesting concentration hiding one layer below the three platforms.

The nine failures share no common cause. A token-service host that failed to reboot (Fly.io), a six-minute telemetry pipeline gap (Vercel), and an upstream-provider disruption in one region (Render) have nothing technically in common. Nobody's incident names another PaaS as a dependency. The timing overlap is real but thin: the window's incidents are spread across the 17th, 20th, 23rd, 24th, 25th, and 27th, and only July 20 has two platforms posting on the same day — Fly.io's auth outage and Render's build degradation, which resemble each other not at all.

But "independent" is not the same as "isolated," and the status pages themselves supply two shared-dependency data points. The first sits just outside the window: on July 16, both Vercel ("GitHub-linked deployments and authentication affected") and Render ("GitHub outage affecting new service creation and service deploys") posted incidents caused by the same upstream event at GitHub. Two competing PaaSes degraded the same day by the same third party is exactly the correlated-failure shape people worry about — it just lives at the Git-hosting layer, not the compute layer. GitHub's own July availability report, which documents eight separate July incidents across Actions, DNS, SSH auth, and more, confirms how busy that shared dependency was all month.

The second is Render's unnamed "upstream provider" behind the Oregon disruption. Every hosted region is somebody's tenant: Render on its infrastructure providers, Vercel's regions on theirs — and Fly.io's own September infra-log entry tracing a Sprites API outage to suspected connectivity loss with its object-storage provider shows the same pattern from the most transparent vendor of the three. The concentration risk in this market is not that three PaaSes share fate with each other — they demonstrably do not — but that each PaaS, and each of its customers, inherits the incident list of providers they never chose and cannot see. Your status page is the union of your vendors' status pages, minus the ones they don't publish.

The transparency gap matters more than the outage count​

There is a second comparison hiding in these nine reports, and it is about disclosure rather than downtime. Rank the three platforms by how much a reader learns, and the order is unambiguous: Fly.io published a named service, a hardware narrative, a replication trade-off, and a remediation direction. Render published timelines, an explicit mitigation (disabling failure reasons), and one opaque attribution ("upstream provider"). Vercel published impact and resolution for five incidents and root cause for none.

None of this is unusual — terse status updates are the industry norm, and GitHub's monthly availability report, with per-incident durations, error rates, and follow-up work items, is the exception that proves how good this genre can be. But the gap matters for a specific reason: the July 23 Drains data loss is unrecoverable by definition, and its report contains no cause, no scope beyond a time window, and no prevention detail beyond "additional monitoring." A six-minute hole in your traces is the kind of event where "what broke" is the entire question, and the status page does not answer it. When evaluating hosted platforms, count the postmortems, not just the incidents: a vendor that explains tkdb in public has given you something no SLA credit can replace — the ability to reason about whether it will happen again.

The honest self-hosted counterpoint​

Everything above could read as an argument for leaving hosted platforms — and the team that runs its own fleet should be honest about what that trade actually buys. Owning the machines does not mean zero incidents. It means the incident list is yours to read instead of theirs.

A self-hosted platform would not have had Vercel's July 23 — but it has its own Julys: the etcd quorum scare, the expand-the-disk-at-2am saga, the CNI upgrade that took forty minutes longer than the runbook promised. None of those appear on anyone's status page, which is precisely the point. What changes is not the incident rate but the incident texture: root cause by construction (the broken thing is a component you chose and can inspect), remediation on your schedule (no waiting for "we are continuing to investigate"), and the pager firmly, unavoidably yours. The Drains lesson cuts both ways — a self-hosted Loki or ClickHouse can lose six minutes of telemetry just as permanently, and there is no vendor to apologize for it.

So the real question these nine incidents pose is not "hosted or self-hosted" but "whose incident list do you want to be on." If you run on Vercel, Fly.io, or Render, your reliability story includes their rough ten days plus GitHub's eight-incident July plus an unnamed upstream provider in Oregon — most of it unexplained. If you run your own fleet, your reliability story includes everything you have not automated yet — all of it, at least, legible. Teams that outgrow the first list do not do it because the second list is shorter. They do it because it is theirs.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with the full state of your fleet readable by you and your agents instead of filtered through someone else's status page. Star the repo on GitHub or deploy your first app today.