Postmortem
ChatGPT, Claude and Grok Down: Self-Host Your AI on a VPS
Last verified: September 7, 2026 · 11 min read · Last verified 2026-09-07: OpenAI, Anthropic and Cursor status-page incident timestamps for Sep 3 re-read directly from their history feeds; RackNerd annual KVM tiers re-checked live and unchanged at $21.99 / $35.99 / $59.99 / $89.99 / $119.99 per year; reachability probe to api.openai.com and api.anthropic.com re-run from my box (both healthy today)
On Thursday September 3, 2026 I lost about ninety minutes of work in a way I had not planned for. My coding agent stopped returning results, so I switched to a chat window in a different tab, and that was broken too. So I tried a third one. Also broken. That was the moment the actual problem became visible: I thought I had three independent AI tools, and what I really had was three front doors into overlapping infrastructure. This article is what I went and checked afterwards, straight from the vendors' own incident histories, and what I changed about where my agent runs. It is a hosting article rather than an AI article, because the failure was a hosting failure.
What Actually Went Down on September 3, 2026
I did not want to work from headlines on this one, because the headline numbers on outage days come from crowd-sourced report counts and they drift. Status pages are better evidence: they are the vendor admitting, in writing and with timestamps, that their own service was broken. Here is what the four relevant status histories actually say about that day. Every row below was read directly from the vendor's incident history or Atom feed.
Artifact 1 — vendor-filed incidents, September 3, 2026, all times UTC (read from official status histories on 2026-09-07):
| Vendor | Incident title (as filed) | First entry | Resolved |
|---|---|---|---|
| Anthropic | Elevated errors for Claude Sonnet 5 | 12:37 | 12:56 |
| Anthropic | Elevated errors for multiple models | 13:26 | 16:23 |
| Cursor | Investigating service degradation (Grok models, Automations, Cloud Agents, Review Agents) | 13:41 | 17:07 |
| Cursor | Elevated errors for Anthropic Models | 14:17 | 16:31 |
| Cursor | Elevated errors for OpenAI Models | 15:17 | 17:05 |
| OpenAI | Elevated errors across ChatGPT and Codex | — | 16:55 |
| Cursor | Degraded performance of Grok 4.6 | 17:42 | 19:21 |
| Cursor | Degraded performance for Grok Bot routine triggers | 23:42 | Sep 4, 00:42 |
Anthropic's resolution note reads "Impact has ended as of 9:16 PT / 16:16 UTC". 9to5Google's live updates recorded services returning at 8:49 a.m. PT and everything normal by 12:38 p.m. PT. xAI's own status page returned HTTP 403 to my request, so Grok's incident is evidenced here through Cursor's filings and press reports rather than xAI's own feed.
Read the table as a shape rather than a list. Three model vendors and one agent product filed overlapping incidents inside roughly a six-hour window, on a day none of them had planned maintenance. The Cursor rows are the most interesting ones, and I will come back to them, because Cursor is not a model vendor at all.
Why Did ChatGPT, Claude and Grok All Fail Together?
The theory that circulated on the day was a regional fault inside Microsoft Azure, the cloud that reportedly carries capacity for all three products. 9to5Google put both halves of that on the record: that the three platforms rely on Azure for cloud services, with other providers including Google in the mix, and that Microsoft says this is not the case. I went looking for a Microsoft post-incident review dated September 3 in Azure's own status history and did not find one in the default view. So I am not going to tell you Azure caused this, because no vendor has published that.
What I will say is that the correlation is the story regardless of which specific component failed. Three vendors who compete with each other, who have separate engineering teams, separate release schedules and separate on-call rotations, degraded inside the same window on the same afternoon. Either that is a coincidence at a scale worth betting against, or there is shared infrastructure underneath the competition. For someone deciding where to run their own workload, both readings lead to the same conclusion: the independence you assume you have across AI vendors is not independence you have verified.
Want to stop depending on a cloud core you do not control? An annual KVM box is the cheapest independent base for your own agent — RackNerd's annual plans start at $21.99/yr and the cost of the experiment is roughly one month of a hosted AI subscription.
Gemini Stayed Up, and That Is the Tell
Google's Gemini did not file an official outage on Google's service-health dashboard during the window. Some users reported problems and several outlets noted those reports were far less widespread than the ones hitting ChatGPT, so I am not claiming Gemini had a flawless afternoon. What I am pointing at is the structural difference: Google runs Gemini on Google's own cloud rather than renting capacity from a competitor's hyperscaler.
This is a cleaner natural experiment than anything I could have designed. Four AI products, similar workloads, similar scale of demand, one afternoon. The ones sharing infrastructure went down together. The one running on infrastructure its own company operates did not file an incident. Model quality had nothing to do with it. Availability followed the infrastructure, and that is the only variable that moved.
The Single Point of Failure You Inherit With Hosted AI
Now back to those Cursor rows, because they are the part that changed my thinking. Cursor is not OpenAI, Anthropic or xAI. It is an independent product with its own engineering team and its own infrastructure. On September 3 it filed four separate incidents, and the titles name the cause each time: upstream Anthropic errors, upstream OpenAI errors, Grok model degradation. Cursor did nothing wrong that day. It went down because the things it depends on went down.
That is dependency inheritance, and it is transitive in a way most of us do not audit. You pick an agent product because it is good. It routes to model vendors you did not pick. Those vendors run on infrastructure you cannot see. When something three layers down has a bad afternoon, your workflow stops and the vendor you actually pay has no ability to fix it for you. Multi-model routing in your client does not fully solve this either — if your fallback models sit on the same infrastructure as your primary, you have configured the appearance of redundancy without the substance.
Option A: Keep Hosted AI, Engineer Around the Outage
I want to be fair to the option most readers will and probably should choose. If your AI usage is interactive and occasional, the correct response to September 3 is not to build infrastructure. It is to configure a fallback and get on with your day.
Practically: keep credentials for at least two model vendors whose infrastructure differs, put a router in front of them so a 5xx from one fails over rather than surfacing to you, and make sure your fallback is not on the same cloud as your primary — which, per the day's evidence, means checking rather than assuming. Google's own-cloud position makes Gemini a genuinely useful diversity pick for a fallback slot for exactly that reason. This path costs you an afternoon of configuration and no monthly spend, and for a lot of people that is the whole correct answer.
Even if you stay hosted, a cheap box is worth having as a landing pad for the pipeline parts that do not need a frontier model. A $21.99/yr RackNerd instance is about the cheapest insurance in this category.
Option B: Self-Host the Agent on a VPS You Control
The other path is to move the parts of your pipeline that do not need frontier intelligence onto a box whose uptime is your problem. This is narrower than "replace ChatGPT", and the narrowness is what makes it work. A 7B or 8B local model will not match Opus 5 on hard reasoning. It will comfortably handle classification, extraction, summarisation, embedding, retrieval, scheduled jobs and tool execution — which in my own pipeline is most of the token volume and nearly all of the scheduled work.
The reachability check below is the one I now run before assuming an upstream problem is mine. It takes seconds and separates "the vendor is down" from "my code is broken", which on September 3 I wasted twenty minutes conflating.
Artifact 2 — upstream reachability probe, run from my box on 2026-09-07:
$ for u in https://api.openai.com/v1/models https://api.anthropic.com/v1/messages; do
curl -s -o /dev/null -w "%{http_code} tls=%{time_appconnect}s ttfb=%{time_starttransfer}s $u\n" --max-time 25 "$u"
done
401 tls=0.011767s ttfb=0.258603s https://api.openai.com/v1/models
405 tls=0.012940s ttfb=0.020160s https://api.anthropic.com/v1/messages 401 and 405 are the healthy answers here: unauthenticated and wrong-method respectively, which means TLS completed and the API answered. A hung TLS handshake, a timeout, or a 5xx is the signal that the problem is upstream and not in your code. On the same run, ping RTT was 2.26 ms average to api.openai.com, 3.02 ms to api.anthropic.com and 7.69 ms to racknerd.com — all five packets returned on each, so nothing on my side was degraded when I took these numbers.
The deployment itself is well-trodden ground and I am not going to re-derive it here — our AI agent VPS and API guide walks through the Ollama-on-Ubuntu install, and cheap VPS for local LLM inference covers what a 7B to 8B model actually needs from the hardware. RackNerd annual plans from $21.99/yr give you a box that keeps running on the afternoons when the hosted stack does not.
What Self-Hosting Does Not Fix
I would rather lose you here than oversell this. Self-hosting trades a dependency you cannot control for a workload you have to carry yourself, and that trade is genuinely wrong for some readers. Here is the honest split.
Decision table — what each path actually gives you:
| Dimension | Hosted AI + multi-vendor fallback | Self-hosted agent on your VPS |
|---|---|---|
| Frontier model quality | Yes — best available | No — 7B/8B class locally |
| Exposure to a shared-cloud event | Yes, unless fallbacks differ by infrastructure | No for the self-hosted portion |
| Who owns uptime | The vendor (you wait) | You (you can act) |
| Ops burden | Near zero | Real — patching, monitoring, restarts |
| Cost shape | Per-token, scales with use | Fixed annual, predictable |
| Data residency control | Vendor policy | Your box, your jurisdiction |
| Right for | Occasional chat, no ops appetite | Daily-driver agents, scheduled jobs, custom pipelines |
If that table lands you on the self-host side, transparent annual pricing is what makes the experiment cheap enough to just try — which is where RackNerd's annual tiers fit. If it lands you on the hosted side, close the tab and go configure a fallback instead; that is a real answer and it costs you nothing.
Picking a Budget VPS for an Always-On AI Agent
Sizing first, because it is where money gets wasted. An agent process that orchestrates tool calls and holds context is comfortable in 1 GB to 2 GB. Adding a local 7B to 8B model at 4-bit quantisation pushes you to 4 GB as the realistic floor, 6 GB to 8 GB if you want headroom for concurrent requests. The plans below were re-read from the vendors on the dates noted.
RackNerd annual KVM tiers — re-verified live on 2026-09-07, unchanged from the August check:
| Plan | vCPU | RAM | SSD | Transfer | Price | Agent fit |
|---|---|---|---|---|---|---|
| 1 GB KVM | 1 core | 1 GB | 20 GB | 3 TB/mo | $21.99/yr | Agent runtime, API-backed only |
| 2 GB KVM | 2 cores | 2 GB | 35 GB | 5 TB/mo | $35.99/yr | Agent + scheduled jobs (sweet spot) |
| 4 GB KVM | 3 cores | 4 GB | 60 GB | 7 TB/mo | $59.99/yr | Local 7B/8B at 4-bit, floor |
| 6 GB KVM | 6 cores | 6 GB | 100 GB | 12 TB/mo | $89.99/yr | Local model with real headroom |
| 8 GB KVM | 7 cores | 8 GB | 150 GB | 20 TB/mo | $119.99/yr | Concurrent requests, larger context |
All tiers: 1 Gbps port, full root access, 1 IPv4, KVM on SolusVM, multiple US and EU locations. Note the vCPU curve is not linear with RAM — the 6 GB plan doubles the cores of the 4 GB plan, which matters more than the extra 2 GB if you are CPU-bound on inference.
The alternatives worth knowing, all whitelisted on this site: Vultr from around $2.50/mo hourly across 13 locations, which is the right pick when you want to spin an inference box up and down rather than run it all year; DigitalOcean from around $4/mo for the cleanest API and docs if you are automating provisioning; Hostinger from $1.99/mo intro on NVMe, with the renewal caveat we document in the VPS pricing traps guide; and Kamatera from around $4/thread when you want dedicated cores for heavier local inference. RackNerd's annual tiers are the ones I actually keep running year-round, because a box that exists specifically to survive someone else's outage should not itself have a billing surprise.
The 1 GB at $21.99/yr and 2 GB at $35.99/yr are the standard always-on agent boxes; step to 4 GB when you add a local model.
How to Break the Shared-Backend Habit This Weekend
Concretely, in the order I would do it, and none of it takes a full day:
- Audit what you actually depend on. List the AI tools in your daily workflow and write down which model vendor each one routes to. The Cursor lesson is that the product name on your invoice is not the dependency. Most people find fewer independent vendors than they expected.
- Add a genuinely diverse fallback. Configure a second model vendor whose infrastructure differs from your primary, and confirm the difference rather than assuming it. This alone would have salvaged part of September 3 for me.
- Take an annual box. A 2 GB tier is enough to start; 4 GB if you know you want a local model on day one. Annual pricing here is deliberate — you want the resilience layer to be a fixed line item, not something that lapses.
- Move the deterministic work over. Scheduled jobs, retrieval, embedding, extraction, tool execution. Anything that does not need frontier reasoning. Follow the Ollama and Ubuntu steps in the agent VPS guide.
- Save the probe as a script. Artifact 2 above, in a file you can run in five seconds. Knowing within seconds whether the failure is yours or theirs is worth more on an outage day than any architecture diagram.
- Back the box up somewhere else. A self-hosted single point of failure is still a single point of failure. Our DigitalOcean outage postmortem lays out a 4-tier fallback framework, and the cloud-shutdown migration guide covers getting your data out when a provider exits.
Spin up a box and do step 4 before the next outage makes the argument for you at a worse moment.
FAQ and Bottom Line
Will self-hosting really protect me from hosted-AI outages? For the portion you self-host, yes — a local model on your own box does not route through OpenAI, Anthropic or xAI. What it will not give you is frontier quality, so the realistic pattern is hybrid: self-host the deterministic work, treat the frontier model as one interchangeable backend. An upstream incident then degrades your output instead of stopping your work.
What actually caused the September 3, 2026 outage? No vendor published a confirmed shared root cause. OpenAI, Anthropic and Cursor each filed their own incidents in the same window; the widely-reported theory was a regional Azure fault, and 9to5Google reported Microsoft saying that was not the case. Strong correlation across three competitors, not an established cause.
Why did Gemini survive? It filed no official outage on Google's dashboard while the others filed on theirs, and it runs on Google's own cloud rather than rented capacity. Some users did report issues, and outlets noted those reports were much less widespread. The takeaway is that availability tracked infrastructure, not model quality.
Is self-hosting worth the effort? If AI is a daily driver — coding agents, scheduled automation, customer-facing workflows — then $35.99 to $59.99 a year removes a dependency class you do not control, roughly one month of a hosted subscription for twelve months of compute. If you use a chat window twice a week, it is overhead and a fallback config is the better answer.
Bottom line. September 3 was not really an AI story. Three competing vendors and one independent agent product filed overlapping incidents in one afternoon while the one running on its own company's cloud did not, and that pattern is a hosting fact rather than a model fact. You cannot fix someone else's infrastructure and you will not get advance warning of the next event. What you can do is make sure the part of your workflow you cannot afford to lose runs somewhere you can reach, restart and reason about. For about the price of one month of a hosted AI subscription, that is a year of a box that is yours.
Get a RackNerd annual VPS from $21.99/yr →
Sources read directly on 2026-09-07: status.openai.com/history and its Atom feed; status.anthropic.com/history and its Atom feed; status.cursor.com/history and its Atom feed; azure.status.microsoft status history (no September 3 post-incident review present in the default view); 9to5Google's September 3 report by Ben Schoon, which carries both the Azure attribution theory and Microsoft's denial; corroborating coverage from Smartprix, NewsBytes, Times Now, Startup Fortune and FinanceFeeds. xAI's status page returned HTTP 403 to my request, so Grok's incident is evidenced here via Cursor's filings and press reports rather than xAI's own feed. Crowd-sourced peak report counts circulating that day are deliberately omitted: I could not verify the specific figures against a primary source, and the vendor-filed timestamps above are stronger evidence anyway. RackNerd pricing and specifications re-read from the live specials page on 2026-09-07. Disclosure: RackNerd links on this page are affiliate links; the pricing quoted is the public rate and is not affected by them.