Cloudflare Outage Map

Community Discussion

Tips? Frustrations? Share them here. Useful comments include a description of the problem, city and postal code.

Beware of "support numbers" or "recovery" accounts that might be posted below. Make sure to report and downvote those comments. Avoid posting your personal information.

Cloudflare Issues Reports

Latest outage, problems and issue reports in social media:

• 
  Mohit (@mohitdotdev) reported 5 minutes ago

  Our in house headless CMS completed migrations from PlanetScale to Cloudflare D1. Things that stood out 1. There were queries which read over 700M rows on a daily basis. I need to look into this as this is too much. 500k requests reading these many rows just isn't correct. Possibly indexing issue. 2. The DB size isn't much but API read logs were being written to the same DB. I would switch to Cloudflare Analytics Engine to count reads. 3. API reads would be moved to KV cache. This way DB reads get eased and expected response time becomes snappy. I hope this can be launched as a headless CMS as internal usages is all thumbs-up.

• 
  Sina Meraji (@sinasanm) reported 6 minutes ago

  changelog v0.98.0: replaced the onboarding (which previously required you to manually type in your Cloudflare account ID and create an API key and select permissions one by one) with "login with Cloudflare," which creates the API key and selects the right permission for you. a few steps less to get started. npm i -g kimiflare

• 
  Jiten Bansal (@bansal_io) reported 7 minutes ago

  I’m building a SaaS where customers will use their own custom domains. Can anyone familiar with Cloudflare for SaaS clarify this for me? The pricing page says $0.10 per additional hostname. Is that $0.10 per hostname per month, or a one-time charge? Any confirmation from someone who has actually used Cloudflare for SaaS billing would be really helpful. It’ll help me choose the right stack for my SaaS. @CloudflareDev @threepointone

• 
  ✨Neil Blumenthal (@MrKryptonBTC) reported 9 minutes ago

  Why glm5.2 (workers AI) is down? 12hrs gone. Still down @Cloudflare

• 
  Maciej Nowak (@mnowak_eth) reported 11 minutes ago

  Cloudflare does not cache your HTML by default. You can be paying for Cloudflare and still have none of your HTML cached there. Would you be able to tell this is your case? By default Cloudflare caches by file extension, not by content type. CSS, JS, images: yes. The HTML document, the thing PHP and the database assemble: not by default. Without an explicit rule, every page view still goes to the origin. I have seen more than one setup where "we have a CDN" meant the logo loads from the edge of the network and everything else works exactly as before. Check the cf-cache-status header. If an HTML document comes back as DYNAMIC, the edge is not caching it at all. What I also hear on calls sometimes are two words traded as if they were two products: CDN and edge. They are not two products. It is the same few hundred machines Cloudflare keeps around the world, and the two names come from different decades. CDN says what the thing does, deliver content. Edge says where it is located, at the far end of the network. For twenty years those were words for the same servers, and then the industry started using edge for the code you can run on them. Nobody planned that, so it is not on you if the two names blur together. What is different is not the name but the job you give those machines. Handing out copies of files, your images, CSS and JS, comes with the account. No decisions, it's just simple distribution, working from the moment you point your domain at them. The other job is running your logic up there: assembling and caching whole HTML pages, telling a logged-in visitor from an anonymous one, holding the product page while letting the basket through untouched. It's not on by default because it needs rules: what may be stored, for whom, for how long, and what wipes it. And you are the one who knows those rules. And the principle that ties this whole series together: cache layers are a cascade, not a set of independent switches. The lower layers have to hit before anything propagates up and reaches the edge. Getting that order right is messy work, and it is the reason a site feels smooth when someone has done it. So before you add another layer, you should be able to say three things about it in plain words. What it stores: files, whole pages, or answers from the database. Who is allowed to get the same copy: everyone, or does a logged-in visitor need their own. And what removes that copy when the content changes, plus who is able to trigger it. If any of the three is a shrug, you probably have something messed up and don't know it yet. We created a great guide to understanding caching specifically for WordPress. Link in comment

• 
  Fern (@Ferrrrrnnnnnn) reported 11 minutes ago

  Hey @AMCTheatres @Cloudflare, might be smart to fix your dogshit rate limiting before you drop tickets for the biggest movie of the decade

• 
  Brad Gessler (@bradgessler) reported 11 minutes ago

  @crqrdotcom Putting your name down for cloudflare.

• 
  Pranjal Paliwal (@betterclever) reported 13 minutes ago

  you can tell a good software engineer apart today by their current advocacy of @Cloudflare primitives and how much they use them to decompose problems in agent native world. literally a litmus test

• 
  Zely (@0xZely) reported 13 minutes ago

  The MIT professor who crashed 10 percent of the internet at 22 posts the free course that runs every AWS outage, every Uber ping, and every Slack notification on earth. MIT charges $85,000 a year to sit in that classroom. He posted every lecture to MIT OpenCourseWare for nothing. Millions have opened lecture one. Almost no engineer has finished all twenty. His name is Robert Morris. He is a professor at MIT CSAIL and one of the four cofounders of Y Combinator, the seed fund behind Airbnb, Dropbox, Stripe, Reddit, and Coinbase. In November 1988 he was a 22-year-old Cornell graduate student. He released a small program that was supposed to count the computers on the internet. It replicated so fast it crashed roughly ten percent of every machine online, and made him the first person ever convicted under the Computer Fraud and Abuse Act. He got three years probation, 400 hours of community service, and a $10,050 fine. Ten years later he cofounded the online store Viaweb with Paul Graham and sold it to Yahoo for $49 million. Seven years after that he cofounded Y Combinator with the same partner. Its portfolio is now worth over $600 billion. The clip in this video is one lecture from MIT 6.824 Distributed Systems, filmed at MIT and posted for free. The words on the board behind him are fault tolerance, availability, recoverability. Those three words decide whether Instagram loads when you open it, whether your Uber arrives, and whether your paycheck hits your account on the first of the month. Morris covers the entire logic of distributed systems in twenty lectures. Everything fails, all the time. A single computer fails once every few years. Ten thousand computers fail hundreds of times a day. The only design that survives is one that assumes failure is normal. Every retail user cursing a spinning wheel is looking at the wrong problem. The miracle is that most of the time it does not spin. Availability beats consistency. You cannot always have both. When the network splits, a system either serves stale data or refuses to serve at all. Amazon picks stale. Your bank picks nothing. Every user who screams at the Slack status page wants Amazon's answer. Every user who screams at a double charge wants the bank's. Replicate everything, trust nothing. Data in one place disappears when that place burns. Data in three places survives two fires. Every photo you have ever taken on an iPhone lives on three continents already. iCloud, Google Photos, and Dropbox are built off the exact lecture on the board. Concurrency is where bugs live. One user at a time is easy. A million users at the same second is not. Race conditions, double spends, lost messages, ghost bookings. Every airline that oversold your flight, every trading app that ate your order, every Ticketmaster that showed you a seat already gone, is a concurrency bug Morris warned about. Partial failure is worse than full failure. A dead server is easy. A slow server that answers half the time is a nightmare. It fools every retry, wastes every resource, and confuses every operator. Every "is it down or is it just me" Twitter search you have ever run is Morris's third slide. Every senior engineer at AWS, Google, and Meta has watched this course. Every startup that raised a Series A in cloud infrastructure hired an alumnus of 6.824. Every AI company training a trillion-parameter model on a cluster is running the same lecture in production. "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." That is Leslie Lamport, the Turing Award winner Morris quotes at the opening of 6.824. It is the exact sentence that explains why your Slack goes down when a data center in Virginia loses power. The full course is free on MIT OpenCourseWare. The lecture notes are on Morris's website. Every equation on the board fits on one screen of code. Almost every senior engineer at AWS, Google, Cloudflare, and Meta has watched 6.824. Almost no founder promising 99.99 percent uptime on their pitch deck has opened lecture one. That is the entire moat. The course is free. The willingness to sit through twenty lectures on partial failure before uploading your money to a payment app, storing your photos in the cloud, or handing your health records to a portal is a much rarer commodity than the confidence to click without them.

• 
  Mike Choi (@guard_if) reported 17 minutes ago

  if you want to run a series A startup: Rails = the entire app. Postgres = source of truth. ClickHouse = analytics. Kafka = getting one into the other. (MSK) Sidekiq = everything async. ECS + EKS = deploys your own models. (GPUs, lol) Terraform = all of it, in code. Grafana + Sentry = knowing what broke. Statsig = flags + experiments. Stripe = money in. Mercury = money out. Loops = email. Intercom = support. Cloudflare = DNS. Vercel = marketing website. Linear + Graphite = shipping. Claude = coding / artifact generation total monthly cost: definitely not $20.

• 
  NorthernChuck (@FroidEtCold) reported 17 minutes ago

  Ported Buzz from Rust to C and called it Hush. Changed the User Interface around and started bolting on pieces. Built using @tetsuoai's writing legible C skill. Included a STUN/TURN server in C as well. The idea being that you can deploy this thing and use it to pin down media paths and enable voice/video. Will be adding support for Cloudflare TURN, eventually

• 
  Reina Cruz 🥼🧤🇨🇺 (@rea1ReinaCruz) reported 22 minutes ago

  @Cloudflare Fix human verification

• 
  Aman (@devjedi404) reported 24 minutes ago

  Update on my Hot Wheels bot: It has officially gone from "random script I'm hoping works" to a proper monitoring pipeline 😭 Also caught a nasty false-positive bug where an ADD button from a recommended product could be mistaken for my wishlisted car. Persistent browser, saved location, concurrent wishlist checks, crash recovery and Cloudflare backoffs are in too. Now I just need Blinkit to actually restock the damn cars.

• 
  Rahul Karajgikar (@Road_Kill11) reported 28 minutes ago

  most agent harnesses are not built to run in the cloud. this is why we rebuilt dexto from the ground up. we had a coding agent CLI similar to claude code, dexto a long time ago, but we were more interesting in making agents run in the cloud on a persistent computer. we started off by running dexto inside a cloud sandbox (e2b). this had some problems: 1. the runtime is heavily coupled to the sandbox. any sandbox outages or issues would kill the agent and were very hard to recover from. 2. credentials. we needed to give dexto access to many external integrations and tools. but we also needed to ensure that credentials weren't readable by the agent. we solved this by making an egress proxy (adds credentials on top of outbound requests from the sandbox so agents never see them). but this was painful and for every external integration we needed to maintain some code 3. price. we realized that for many of our use-cases (content creation, research, monitoring automations), the agent actually didn't need to read or write files. this pushed us to think that maybe it would be better if dexto ran OUTSIDE the sandbox, but could use the sandbox whenever it needed to write a file or run some command on the computer. while researching how agents could run outside the sandbox, i was very impressed with cloudflare's primitives. durable objects and workflows seemed extremely promising for what we needed and had good pricing. so i tried to deploy dexto on cloudflare. while doing this, i realized that our entire harness was designed assuming the agent would be running on a persistent machine and stored everything in-memory. this wouldn't work in a serverless environment. and interestingly, pretty much EVERY open-source harness you see (codex, opencode, etc.) has this same problem. so we redesigned our core primitives from the ground up, with the goal that these primitives should be able to power a local cli, webui, or desktop app, but ALSO be able to run on any cloud environment (cloudflare, railway, vercel, etc.). we changed every single primitive we had in dexto/core (storage, approvals, system prompt, skills, compaction logic, model registry, tool implementations) to be injectable from consumers so that they could define exactly how they needed dexto to run based on the required environment. while core just defined the shapes and the agent loop logic. now we're running dexto cloud fully outside the sandbox on cloudflare's stack, which has some amazing advantages: 1. dexto gets a persistent cloud computer with a browser and a terminal - but it only uses it when it needs to. this means that for requests that don't need a sandbox (like generating a video, or searching the web), our users spend $0 in compute costs. 2. the compute is now replaceable. it's not really an issue if we the sandbox has issues, or gets sandbox gets corrupted. we just replace the sandbox and move on. and only file writes/reads really are affected. 3. the agent loop is fully durable and resumable at any point, and don't cost extra while waiting. this means that dexto can wait 365 days for an approval, costing you no extra money. it also means if dexto fails something at any point, it can easily resume from the last safe point instead of having to re-run everything from scratch again. 4. credentials are easy! since the agent runs on a serverless environment, we don't need an egress proxy for 99% of normal requests. credentials never live on the sandbox, agents just hit internal apis and the credentials are managed separately so agents never see them. now we only use an egress proxy for a few specific CLIs that run on the sandbox (gh cli) if you're interested to learn more about harness design, and maybe see some cool demos and feature releases, follow along!

• 
  Sindhu Biswal (@sindhubiswal) reported 32 minutes ago

  @frantzfries cloudflare didn't build a new moat, they repositioned an existing one (network layer control) for a buyer that didn't have budget for it yet. that kind of positioning velocity only works because the capability was already sitting there waiting for demand to catch up.