Uptime Report Research · Post-mortem anthology

Cloudflare Outage History: 27 of 40 Post-Mortems Trace Back to Cloudflare’s Own Changes

Cloudflare outage history, read from Cloudflare’s own post-mortems: we found 40 public write-ups of Cloudflare service outages from 2012 to February 2026, and 27 of them began with a software release or configuration change Cloudflare made itself. All 8 outages that broke the core network globally or for a quarter or more of traffic were self-inflicted. The median outage lasted 1 h 15 min.

27 of 40post-mortem outages that began with Cloudflare’s own release or configuration change
8 of 8global core-network outages caused by a Cloudflare change
8 of 40caused by a third party, a route leak or a traffic surge
1 h 15 minmedian duration (34 outages with a stated length)

Cloudflare publishes unusually detailed post-mortems on its blog. We collected every one we could find that explains an outage of Cloudflare’s own services, read each, and recorded the date, duration, scope, what failed and one sentence in Cloudflare’s own words. Then we downloaded all 6,534 incidents from Cloudflare’s status page API, back to its launch in 2014, to see how the rare big failures sit against the daily stream of smaller ones.

Every Cloudflare outage with a public post-mortem

Software or rule release (9)Configuration or operational change (18)Latent software bug (2)Hardware or facility failure (3)Third party, routing or traffic (8)Shaded card: core network, global or 25%+ of traffic

Feb 20, 20266 h 7 min

About 25% of BYOIP prefixes

A change to how BYOIP prefixes are managed withdrew about 1,100 customer prefixes, some of which had to be restored by hand.

“This issue was caused by a change that Cloudflare made to how our network manages IP addresses onboarded through the BYOIP pipeline.”

Jan 22, 202625 min

IPv6 traffic through Miami

An automated routing policy change on a Miami router leaked BGP prefixes from peers to other peers and providers.

“On January 22, 2026, an automated routing policy configuration error caused us to leak some Border Gateway Protocol (BGP) prefixes unintentionally from a router at our data center in Miami, Florida.”

Jan 8, 2026duration not stated

1.1.1.1 for some DNS clients

A memory-saving 1.1.1.1 release changed the order of CNAME records in answers, and some DNS clients that expect the CNAME first failed.

“On January 8, 2026, a routine update to 1.1.1.1 aimed at reducing memory usage accidentally triggered a wave of DNS resolution failures for users across the Internet.”

Dec 5, 202525 min

About 28% of HTTP traffic

While raising the WAF body buffer to cover a React Server Components flaw, a second change to disable a test tool went out through the global configuration system with no gradual rollout.

“Instead, it was triggered by changes being made to our body parsing logic while attempting to detect and mitigate an industry-wide vulnerability disclosed this week in React Server Components.”

Nov 18, 20253 h 10 min

Core network traffic worldwide

A database permissions change doubled the size of a Bot Management feature file, which exceeded a limit in the proxy software on every machine.

“Instead, it was triggered by a change to one of our database systems’ permissions which caused the database to output multiple entries into a “feature file” used by our Bot Management system.”

Sep 12, 20251 h 15 min

Dashboard and many APIs

A dashboard release with a React bug flooded the Tenant Service API with calls just as a new Tenant Service version was deployed.

“The incident’s impact stemmed from several issues, but the immediate trigger was a bug in the dashboard.”

Aug 21, 20253 h 11 min

Traffic between Cloudflare and AWS us-east-1

One customer’s surge of requests from AWS us-east-1 saturated the peering links between Cloudflare and AWS.

“The incident was a result of a surge of traffic from a single customer that overloaded Cloudflare’s links with AWS us-east-1.”

Jul 14, 20251 h 2 min

1.1.1.1 resolver, worldwide

A June 6 service-topology configuration error tied 1.1.1.1’s prefixes to an unused service; a later change activated it and withdrew the resolver’s routes.

“The outage occurred because of a misconfiguration of legacy systems used to maintain the infrastructure that advertises Cloudflare’s IP addresses to the Internet.”

Jun 12, 20252 h 28 min

Workers KV, WARP, Access, Gateway, Turnstile and more

A third-party cloud provider that backs part of Workers KV storage had an outage, and many Cloudflare products depend on KV.

“Part of this infrastructure is backed by a third-party cloud provider, which experienced an outage today and directly impacted availability of our KV service.”

Mar 21, 20251 h 7 min

R2 and dependent products

During a credential rotation, new R2 Gateway credentials went to a development instance, and the old ones were deleted from production.

“While rotating credentials used by the R2 Gateway service (R2’s API frontend) to authenticate with our storage infrastructure, the R2 engineering team inadvertently deployed the new credentials (ID and key pair) to a development instance of the service instead of production.”

Feb 6, 202559 min

R2 and dependent products

An abuse-remediation action against a phishing report disabled the production R2 Gateway service.

“The incident occurred due to human error and insufficient validation safeguards during a routine abuse remediation for a report about a phishing site hosted on R2.”

Nov 14, 20243 h 30 min

Cloudflare Logs (about 55% of logs lost)

A configuration change for a new Logpush dataset briefly told the log forwarder that no customer had logs configured, and a fail-open safeguard then overloaded the pipeline.

“On November 14, 2024, we made a change to support an additional dataset for Logpush.”

Sep 17, 20241 h

1,661 Business plan websites

During routine IP renumbering maintenance, 15 IPv4 prefixes still in use were withdrawn because an earlier code change had silently skipped some websites.

“On September 17, 2024, during routine maintenance, Cloudflare inadvertently stopped announcing fifteen IPv4 prefixes, affecting some Business plan websites for approximately one hour.”

Jun 27, 20247 h 37 min

1.1.1.1 from about 300 networks

Another network hijacked 1.1.1.1/32 and a second network leaked 1.1.1.0/24 upstream.

“The root cause was a mix of BGP (Border Gateway Protocol) hijacking and a route leak.”

Jun 20, 20241 h 54 min

CDN, 1.4 to 2.1% of HTTP requests at peak

A newly deployed DDoS mitigation rule triggered a latent bug in rate limiting that sent some processes into an infinite loop, on top of backbone congestion.

“A new Distributed Denial-of-Service (DDoS) mitigation mechanism deployed between 14:14 and 17:06 UTC triggered a latent bug in our rate limiting system”

Mar 26, 20247 min

Control plane (failed over automatically)

The same Oregon facility lost power again; after five months of Code Orange work, APIs and dashboards failed over without human intervention.

“On March 26, 2024, at 14:58 UTC, PDX01 lost power and our systems began to react.”

Nov 2, 20231 d 16 h 41 min

Control plane, analytics and logs

A utility feed problem and a ground fault took down the Flexential PDX-04 facility in Oregon, and services not yet in the high-availability cluster went with it.

“The incident lasted from November 2 at 11:44 UTC until November 4 at 04:25 UTC.”

Oct 30, 202337 min

Workers KV, Pages, Access, Gateway and others

A misconfigured deployment tool made Workers KV answer every request with 401 Unauthorized, breaking products that read configuration from KV.

“This was due to the misconfiguration of a deployment tool used by Workers KV.”

Oct 4, 20234 h

1.1.1.1, WARP and Zero Trust DNS

Resolvers could not parse a new ZONEMD record in the root zone, kept a stale copy for two weeks, and began failing when its signatures expired.

“This outage was an internal software error and not the result of an attack.”

Jul 17, 2023duration not stated

Workers KV and products built on it

Repeated attempts to move traffic onto a new KV backend surfaced bugs, then an older configuration was progressed during a rollout and re-enabled the new backend.

“Over the last couple of months, Workers KV has suffered from a series of incidents, culminating in three back-to-back incidents during the week of July 17th, 2023.”

Jul 8, 20239 h 56 min

Origin DNS in Asia Pacific, up to 7% of DNS queries

Verisign’s .com and .net nameservers in Asia Pacific served expired DNSSEC signatures until Cloudflare rerouted its queries to the US west coast.

“caused by invalid DNSSEC signatures from Verisign .com and .net Top Level Domain (TLD) nameservers.”

Jan 24, 20232 h 1 min

Access, Workers, Zero Trust, parts of the control plane

A release meant to show when a service token was last used overwrote token metadata, invalidating tokens that internal services depended on.

“Several Cloudflare services became unavailable for 121 minutes on January 24, 2023 due to an error releasing code that manages service tokens.”

Oct 25, 20226 h

Tiered Cache, Images, Bandwidth Alliance (530 errors)

A software release of a CDN component carried a bug that returned 530 errors for sites using Tiered Cache, Images or Bandwidth Alliance.

“Today, a change to our Tiered Cache system caused some requests to fail for users with status code 530.”

Jun 21, 20221 h 15 min

19 data centers carrying 50% of requests

A BGP prefix policy change rolled to the spines of the 19 busiest data centers re-ordered terms and withdrew critical prefixes.

“This outage was caused by a change that was part of a long-running project to increase resilience in our busiest locations.”

Jan 24, 20221 h 49 min

24 hostnames sent to the wrong origin

A migration of custom hostnames to Cloudflare for SaaS activated 24 blocked hostnames, including www.cloudflare.com, under another customer’s configuration.

“On January 24, 2022, as a result of an internal Cloudflare product migration, 24 hostnames (including www.cloudflare.com ) that were actively proxied through the Cloudflare global network were mistakenly redirected to the wrong origin.”

Dec 16, 202130 min

All web requests, delayed up to 5 seconds

A manual rollback of a Front Line release, combined with a cron job script missing the pipefail option, fed empty addressing data to the DDoS system.

“Between 20:10 and 20:40 UTC on December 16, 2021, web requests served by Cloudflare were artificially delayed by up to five seconds before being processed.”

Nov 2, 20206 h 33 min

API and dashboard

A network switch failed partially, giving etcd cluster members conflicting views, which cascaded into database failovers and slow replica rebuilds.

“On November 2, 2020, Cloudflare had an incident that impacted the availability of the API and dashboard for six hours and 33 minutes.”

Jul 17, 202027 min

20 locations, about 50% of traffic

A router configuration change in Atlanta, made to relieve congestion, sent all backbone traffic to Atlanta and overwhelmed it.

“Today a configuration error in our backbone network caused an outage for Internet properties and Cloudflare services that lasted 27 minutes.”

Apr 15, 20204 h 21 min

Dashboard and API

Technicians decommissioning a cabinet in a core data center removed a patch panel that carried all of its external connectivity.

“As part of planned maintenance at one of our core data centers, we instructed technicians to remove all the equipment in one of our cabinets.”

Jul 2, 201927 min

Proxy, CDN and WAF worldwide (502 errors)

A new WAF managed rule contained a regular expression that backtracked badly and pinned every HTTP CPU core worldwide; it was deployed globally in one go.

“On July 2, we deployed a new rule in our WAF Managed Rules that caused CPUs to become exhausted on every CPU core that handles HTTP/HTTPS traffic on the Cloudflare network worldwide.”

May 31, 201817 min

1.1.1.1 resolver, worldwide

After a new code release, the Gatebot DDoS system read 1.1.1.1 resolver traffic as an attack and blocked it worldwide.

“On May 31, 2018 we had a 17 minute outage on our 1.1.1.1 resolver service; this was our doing and not the result of an attack.”

Jan 1, 20176 h 45 min

DNS for CNAME customers, about 0.2% of queries

The leap second made a time value go negative inside Cloudflare’s RRDNS software, which then panicked on some CNAME lookups.

“At midnight UTC on New Year’s Day, deep inside Cloudflare’s custom RRDNS software, a number went negative when it should always have been, at worst, zero.”

Jun 20, 2016duration not stated

Origin reachability (522 errors)

Massive packet loss on the Telia Carrier backbone, a major transit provider, until Cloudflare shut its Telia ports.

“Today, Jun 20, at 12:10 UTC, our systems again detected massive packet loss on one of our major transit provider backbone networks: Telia Carrier.”

Jul 6, 2015duration not stated

Sites whose origins use CNAMEs hosted at Dyn

A DNS configuration problem at Dyn broke origin lookups for Cloudflare customers who pointed to Dyn-hosted names, producing 1001 errors.

“Ultimately, the outage was identified as Dyn, another major DNS operator, having issues with their own DNS configuration.”

Oct 2, 2014duration not stated

Sites in parts of the world

A Latin American ISP leaked BGP routes and pulled traffic for Cloudflare data centers worldwide into one site in Medellin.

“This downtime was the result of a BGP route leak by Internexa, an ISP in Latin America.”

May 31, 201320 min

About 10% of connections

A transit provider’s network consolidation shifted a route upstream, sending East Coast and European traffic to Los Angeles, which overloaded.

“Today’s issue was an indirect result of this migration.”

Mar 3, 20131 h 2 min

All services, DNS and proxy

An operator pushed a Flowspec router rule to drop impossibly large attack packets; the rule hit a router bug and every edge router failed.

“This morning at 09:47 UTC CloudFlare effectively dropped off the Internet.”

Sep 15, 2012duration not stated

European data centers

While fighting a large DDoS attack, the team applied a rate limit meant for one customer to many more, and traffic in Europe fell away.

“Second, we misapplied a network rate limit in an attempt to mitigate a large DDoS our ops team had been fighting throughout the night.”

May 2, 201215 min

Proxy network, about 75% of traffic

During maintenance in Hong Kong, outbound routes were entered on the inbound interface, so one offline data center announced all of Cloudflare’s address space.

“At some point, the out-bound routes were entered into the in-bound interface.”

Feb 24, 201230 min

DNS in 10 of 14 data centers

While a new DNS system was being pushed, the primary DNS database was deleted during troubleshooting and the empty data propagated within minutes.

“In the process of diagnosing the minor issue, the primary DNS database was deleted.”

Newest first. Dates are the day impact began, in UTC. Duration is the impact window Cloudflare states or gives start and end times for; “about” values are Cloudflare’s own approximations. Quotes are verbatim from each post-mortem.

Are big Cloudflare outages mostly self-inflicted?

Yes. We assigned each post-mortem to the event that set it off. 9 began with a software or rule release and 18 with a configuration or operational change, such as a router policy push, a database permissions change, a credential rotation or a maintenance task. Together that is 27 of 40. Only 2 were latent bugs that surfaced with no recent change (the 2017 leap second and the 2023 root zone record), 3 were hardware or facility failures, and 8 came from outside: transit providers, route leaks by other networks, a third-party cloud provider and one customer’s traffic surge.

Software or rule release (9)Configuration or operational change (18)Latent software bug (2)Hardware or facility failure (3)Third party, routing or traffic (8)

Core network, global or 25%+ of trafficCore network, global or 25%+ of traffic: 2 software or rule release2Core network, global or 25%+ of traffic: 6 configuration or operational change68 of 8 own changeOne product or a product setOne product or a product set: 4 software or rule release4One product or a product set: 5 configuration or operational change5One product or a product set: 1 latent software bug1One product or a product set: 1 third party, routing or traffic19 of 11 own changeControl plane (dashboard, API, analytics)Control plane (dashboard, API, analytics): 1 software or rule release1Control plane (dashboard, API, analytics): 1 configuration or operational change1Control plane (dashboard, API, analytics): 3 hardware or facility failure32 of 5 own changeRegional or partialRegional or partial: 2 software or rule release2Regional or partial: 6 configuration or operational change6Regional or partial: 1 latent software bug1Regional or partial: 7 third party, routing or traffic78 of 16 own change

Count of post-mortems by the widest impact Cloudflare describes. “Own change” means a software release or a configuration or operational change by Cloudflare.

The pattern is sharpest at the top. Every one of the 8 outages where the core network failed worldwide or for at least a quarter of traffic traces to a Cloudflare change: the Hong Kong route mistake in 2012, a Flowspec rule in 2013, the WAF regular expression in 2019, an Atlanta router configuration in 2020, a manual rollback in 2021, a BGP policy change in 2022, and the two late-2025 outages. External causes cluster in the “regional or partial” row, where Cloudflare could route around the problem. Since 2019, 22 of 30 post-mortems describe self-inflicted outages.

Cloudflare reached the same conclusion. After the November 18 and December 5, 2025 outages, it said the global configuration system “does not perform gradual rollouts”, and in December it announced a resilience plan called Code Orange: Fail Small, which it reported complete on May 1, 2026.

How long Cloudflare outages last

Software or rule release (9)Configuration or operational change (18)Latent software bug (2)Hardware or facility failure (3)Third party, routing or traffic (8)Large dots: global core-network outages

5 min15 min1 h4 h1 day2 days2012'13'14'15'16'17'18'19'20'21'22'23'24'252026n/s2012-02-24: DNS in 10 of 14 data centers, 30 min, configuration or operational change2012-05-02: Proxy network, about 75% of traffic, 15 min, configuration or operational change2012-09-15: European data centers, not stated, configuration or operational change2013-03-03: All services, DNS and proxy, 1 h 2 min, configuration or operational change2013-05-31: About 10% of connections, 20 min, third party, routing or traffic2014-10-02: Sites in parts of the world, not stated, third party, routing or traffic2015-07-06: Sites whose origins use CNAMEs hosted at Dyn, not stated, third party, routing or traffic2016-06-20: Origin reachability (522 errors), not stated, third party, routing or traffic2017-01-01: DNS for CNAME customers, about 0.2% of queries, 6 h 45 min, latent software bug2018-05-31: 1.1.1.1 resolver, worldwide, 17 min, software or rule release2019-07-02: Proxy, CDN and WAF worldwide (502 errors), 27 min, software or rule release2020-04-15: Dashboard and API, 4 h 21 min, configuration or operational change2020-07-17: 20 locations, about 50% of traffic, 27 min, configuration or operational change2020-11-02: API and dashboard, 6 h 33 min, hardware or facility failure2021-12-16: All web requests, delayed up to 5 seconds, 30 min, software or rule release2022-01-24: 24 hostnames sent to the wrong origin, 1 h 49 min, configuration or operational change2022-06-21: 19 data centers carrying 50% of requests, 1 h 15 min, configuration or operational change2022-10-25: Tiered Cache, Images, Bandwidth Alliance (530 errors), 6 h, software or rule release2023-01-24: Access, Workers, Zero Trust, parts of the control plane, 2 h 1 min, software or rule release2023-07-08: Origin DNS in Asia Pacific, up to 7% of DNS queries, 9 h 56 min, third party, routing or traffic2023-07-17: Workers KV and products built on it, not stated, software or rule release2023-10-04: 1.1.1.1, WARP and Zero Trust DNS, 4 h, latent software bug2023-10-30: Workers KV, Pages, Access, Gateway and others, 37 min, configuration or operational change2023-11-02: Control plane, analytics and logs, 1 d 16 h 41 min, hardware or facility failure2024-03-26: Control plane (failed over automatically), 7 min, hardware or facility failure2024-06-20: CDN, 1.4 to 2.1% of HTTP requests at peak, 1 h 54 min, software or rule release2024-06-27: 1.1.1.1 from about 300 networks, 7 h 37 min, third party, routing or traffic2024-09-17: 1,661 Business plan websites, 1 h, configuration or operational change2024-11-14: Cloudflare Logs (about 55% of logs lost), 3 h 30 min, configuration or operational change2025-02-06: R2 and dependent products, 59 min, configuration or operational change2025-03-21: R2 and dependent products, 1 h 7 min, configuration or operational change2025-06-12: Workers KV, WARP, Access, Gateway, Turnstile and more, 2 h 28 min, third party, routing or traffic2025-07-14: 1.1.1.1 resolver, worldwide, 1 h 2 min, configuration or operational change2025-08-21: Traffic between Cloudflare and AWS us-east-1, 3 h 11 min, third party, routing or traffic2025-09-12: Dashboard and many APIs, 1 h 15 min, software or rule release2025-11-18: Core network traffic worldwide, 3 h 10 min, configuration or operational change2025-12-05: About 28% of HTTP traffic, 25 min, configuration or operational change2026-01-08: 1.1.1.1 for some DNS clients, not stated, software or rule release2026-01-22: IPv6 traffic through Miami, 25 min, configuration or operational change2026-02-20: About 25% of BYOIP prefixes, 6 h 7 min, configuration or operational change2025/112019/072023/11

Log scale. n/s: Cloudflare did not state a duration. Hover for details.

The median post-mortem outage lasted 1 h 15 min. Global core outages are short by comparison (median 28 min) because the fix is usually a rollback: the 2019 WAF rule was switched off globally 27 min after impact began. Long outages are mostly control plane failures and partial problems that took hours to find. The November 2023 Oregon power failure kept parts of the dashboard, API and analytics down for 1 d 16 h 41 min, and the February 20, 2026 BYOIP withdrawal ran 6 h 7 min, mostly spent restoring prefix configurations.

Cloudflare outage history on the status page

Post-mortems are the exception. Cloudflare’s status page has logged 5,943 incidents since October 2014, not counting 591 items marked as completed maintenance. Most are rated minor, and since 2023 most name a service component; only 6% named just a data center location. The count has risen every year since 2019, from 235 to 799 in 2025. From January 1 to October 14, 2026 there were 776, up 27% on the same period of 2025 (612).

CriticalMajorMinorNo impact

02004006008002015: 130 none impact2015: 270 minor impact2015: 36 major impact43620152016: 76 none impact2016: 509 minor impact2016: 8 major impact59320162017: 10 none impact2017: 226 minor impact2017: 4 major impact24020172018: 49 none impact2018: 170 minor impact2018: 14 major impact2018: 1 critical impact23420182019: 61 none impact2019: 135 minor impact2019: 29 major impact2019: 10 critical impact23520192020: 91 none impact2020: 198 minor impact2020: 37 major impact2020: 2 critical impact32820202021: 147 none impact2021: 253 minor impact2021: 49 major impact2021: 4 critical impact45320212022: 157 none impact2022: 308 minor impact2022: 38 major impact2022: 3 critical impact50620222023: 140 none impact2023: 463 minor impact2023: 26 major impact2023: 6 critical impact63520232024: 123 none impact2024: 504 minor impact2024: 32 major impact2024: 7 critical impact66620242025: 101 none impact2025: 646 minor impact2025: 39 major impact2025: 13 critical impact79920252026: 122 none impact2026: 625 minor impact2026: 24 major impact2026: 5 critical impact7762026*

*2026 runs to retrieval on October 15. Impact is the level Cloudflare set on each incident. Year of incident start, UTC. 2014 (from October 29) is left out of the chart.

More incidents does not mean more big outages. Incidents rated critical are rare: 51 since 2018, with 13 in 2025 and 5 so far in 2026 (against 10 by the same date in 2025). Cloudflare has also added many products since 2019, and each one gets its own status component. The median incident since 2023 was open for 1.3 hours.

Year Incidents No impact Minor Major Critical Median open Post-mortems
2015 436 130 270 36 0 2.7 h 1
2016 593 76 509 8 0 3.0 h 1
2017 240 10 226 4 0 3.8 h 1
2018 234 49 170 14 1 2.7 h 1
2019 235 61 135 29 10 2.2 h 1
2020 328 91 198 37 2 1.1 h 3
2021 453 147 253 49 4 1.3 h 1
2022 506 157 308 38 3 1.3 h 3
2023 635 140 463 26 6 1.2 h 6
2024 666 123 504 32 7 1.3 h 5
2025 799 101 646 39 13 1.3 h 8
2026* 776 122 625 24 5 1.4 h 3

Which Cloudflare services have the most incidents?

Since January 2023 the Dashboard was named in 212 incidents, Workers in 171 and the network in 169. Developer platform products (Workers, R2, Durable Objects, Pages) appear far more often than the CDN cache itself, and R2 and Workers KV failures account for 5 of the 22 write-ups since 2023.

DashboardDashboard: 212 incidents since 2023212WorkersWorkers: 171 incidents since 2023171NetworkNetwork: 169 incidents since 2023169R2R2: 155 incidents since 2023155APIAPI: 129 incidents since 2023129AnalyticsAnalytics: 113 incidents since 2023113Durable ObjectsDurable Objects: 102 incidents since 2023102PagesPages: 102 incidents since 2023102Cloudflare One ClientCloudflare One Client: 85 incidents since 202385Zero TrustZero Trust: 79 incidents since 202379CDN/CacheCDN/Cache: 77 incidents since 202377AccessAccess: 74 incidents since 202374

Status incidents since January 1, 2023 that list each service component. One incident can name several.

Is Cloudflare down? How to check

This page is a record of past outages, not a live monitor. When sites start failing, these checks separate a Cloudflare outage from a problem at one site:

  1. Open the status page. cloudflarestatus.com lists open incidents by service and location. During the November 2025 outage Cloudflare opened its critical status incident 28 minutes after impact began, so give it a few minutes.
  2. Poll the API, not the page. Cloudflare asks automated tools to use /api/v2/summary.json or /api/v2/incidents/unresolved.json with an identifiable User-Agent. Wire it into your PSA or alerting tool.
  3. Test more than one site. If several unrelated sites behind Cloudflare fail at once, it is likely Cloudflare. If only one fails, look at that site’s origin server first.
  4. Check the dashboard separately. In 5 of the 40 post-mortems only the dashboard, API or analytics failed while traffic kept flowing, so a dashboard error does not mean visitors are affected.

What this means for MSPs

Treat Cloudflare’s change process as your risk. 27 of 40 post-mortems began with a Cloudflare change, and none of the global outages were caused by an attack. You cannot stop those changes, so the useful controls are on your side: know which clients depend on Cloudflare for DNS, proxying, Zero Trust access or storage, and have a documented bypass for each one.

Plan a bypass for the proxy, not just the origin. In global proxy outages the origin servers were fine. Keeping DNS records exportable, keeping a tested way to point a critical record straight at the origin, and keeping origin firewall rules that can be opened in an emergency all shorten a 3-hour outage for the clients that matter most. Weigh those steps against the uptime targets in your client contracts; our 99.9% uptime calculator and SLA review shows how little downtime a monthly 99.9% target allows.

Watch dependency chains in the developer platform. The June 12, 2025 outage started at a third-party cloud provider behind Workers KV and spread to Access, WARP and Gateway, which means a storage failure could lock users out of Zero Trust. AWS has the same pattern of regional services taking dependents down with them, as our AWS outage history shows, and GitHub’s record, covered in our analysis of GitHub outages, points the same way.

Use 1.1.1.1 with a fallback. The public resolver appears in 5 post-mortems, including a 62-minute global outage in July 2025. Configure a second resolver from a different provider on client networks.

Frequently asked questions

What caused the Cloudflare outage?

The largest recent one, on November 18, 2025, was triggered by a database permissions change that doubled the size of a Bot Management feature file; the proxy software on every machine had a size limit below that, so it failed. Core traffic was largely back by 14:30 UTC, 3 h 10 min after it began. Across all 40 post-mortems we found, 27 began with Cloudflare’s own release or configuration change.

How often does Cloudflare have outages?

Cloudflare’s status page logged 799 incidents in 2025 and 776 from January 1 to October 14, 2026, up 27% on the same period of 2025. Most are rated minor. Cloudflare has written 40 public post-mortems for service outages since 2012, including 8 for 2025 events and 3 so far for 2026.

How long do Cloudflare outages last?

The median post-mortem outage lasted 1 h 15 min (34 events with a stated duration). The 8 global core-network outages had a median of 28 min. The longest was the November 2023 Oregon data center power failure, which affected the dashboard, API and analytics for 1 d 16 h 41 min, while traffic kept flowing.

Is Cloudflare down right now?

This page is a history, not a live monitor. Check cloudflarestatus.com, which Cloudflare updates during incidents, and its JSON feed at /api/v2/summary.json. If only one site fails while others behind Cloudflare load, the problem is more likely that site’s own server.

What was the worst Cloudflare outage?

By reach, the July 2, 2019 WAF rule outage and the November 18, 2025 feature-file outage both broke proxied traffic worldwide; in 2019 traffic dropped by as much as 82% for 27 min. By duration, the November 2, 2023 control plane outage lasted 1 d 16 h 41 min, but traffic through the network kept working.

What happens when Cloudflare goes down?

It depends on which part fails. In the 8 core-network outages, visitors to sites behind Cloudflare saw error pages or could not connect. In 5 control plane outages, sites kept working but customers could not log in, change settings or purge cache. Product outages, such as R2 in February and March 2025, hit only customers of that product and services built on it.

Download the data. cloudflare-outage-postmortems-2012-2026.csv (CSV). Licensed under CC BY 4.0: free to reuse with attribution to The Uptime Report.

Methodology

Post-mortems. We listed candidate posts from Cloudflare’s live and archived (Internet Archive, 2022 and 2024 captures) “Post Mortem” and “Outage” tag pages and a keyword sweep of the URLs in the blog’s post sitemaps, then read each candidate. We included a post when it explains an incident in which a Cloudflare service failed for Cloudflare customers. We excluded security incidents, outages at other companies that Cloudflare only observed (Facebook, Dyn in 2016, the .fj and .de top-level domains), a 2020 filtering mistake that blocked the wrong sites without an availability failure, planned maintenance, and follow-up posts that cover an event already counted (the July 2019 placeholder post, Code Orange updates, the Workers KV redesign). The July 2023 Workers KV write-up covers three incidents in one week and counts once. Coverage is as of October 15, 2026; the newest qualifying post covers February 20, 2026.

Coding. Each event gets one cause category for what set it off: a software or rule release, a configuration or operational change (including maintenance actions, migrations and credential rotations), a latent software bug with no recent change, a hardware or facility failure, or an external cause. Scope is the widest impact Cloudflare describes. Durations are the impact window Cloudflare states; where it gives start and end times we computed the difference. Every date, time and quote shown is checked by our build script against the saved text of the post.

Status page. All incidents from Cloudflare’s status API (/api/v3/history?type=incident, the paginated JSON endpoint behind cloudflarestatus.com/history), retrieved October 15, 2026: 6,534 records from 2014-10-29 to 2026-10-14. We dropped 591 records with status “completed”, which are maintenance windows. Durations run from the incident start to its resolution time. Impact levels are Cloudflare’s own.

Limitations. Cloudflare chooses which incidents get a post-mortem, so this is not a complete list of significant outages, and older posts may be missing if they no longer carry the tags we used. Cause categories are our reading of each post. Status page counts depend on how Cloudflare records incidents, which changed as products and data center locations were added. Licensing: Cloudflare’s blog and status data are not openly licensed, so we publish facts, our own coding and short attributed quotes only.

Not advice. This is an analysis of public incident records, not a recommendation for any specific environment.

Cite as:The Uptime Report. "Cloudflare Outage History: 27 of 40 Post-Mortems Trace Back to Cloudflare's Own Changes." October 2026. https://theuptimereport.com/cloudflare-outage/

References

  1. Cloudflare Status API documentation and incident history. Accessed October 2026.
  2. Cloudflare Blog, posts tagged Post Mortem. Accessed October 2026.
  3. Cloudflare Blog, “Post Mortem: The Ugly, the Bad & the Good”, February 24, 2012. Accessed October 2026.
  4. Cloudflare Blog, “Today’s Outage Post Mortem”, May 2, 2012. Accessed October 2026.
  5. Cloudflare Blog, “Post Mortem: What Yesterday’s Network Outage Looked Like”, September 16, 2012. Accessed October 2026.
  6. Cloudflare Blog, “Today’s Outage Post Mortem”, March 3, 2013. Accessed October 2026.
  7. Cloudflare Blog, “Today’s Network Issue”, May 31, 2013. Accessed October 2026.
  8. Cloudflare Blog, “Route leak incident on October 2, 2014”, October 2, 2014. Accessed October 2026.
  9. Cloudflare Blog, “The Internet is a cooperative system: CNAME to Dyn DNS outage of 6 July 2015”, July 6, 2015. Accessed October 2026.
  10. Cloudflare Blog, “A Post Mortem on this Morning’s Incident”, June 21, 2016. Accessed October 2026.
  11. Cloudflare Blog, “How and why the leap second affected Cloudflare DNS”, January 1, 2017. Accessed October 2026.
  12. Cloudflare Blog, “Today we mitigated 1.1.1.1”, June 1, 2018. Accessed October 2026.
  13. Cloudflare Blog, “Details of the Cloudflare outage on July 2, 2019”, July 12, 2019. Accessed October 2026.
  14. Cloudflare Blog, “Cloudflare Dashboard and API Outage on April 15, 2020”, April 16, 2020. Accessed October 2026.
  15. Cloudflare Blog, “Cloudflare outage on July 17, 2020”, July 18, 2020. Accessed October 2026.
  16. Cloudflare Blog, “A Byzantine failure in the real world”, November 27, 2020. Accessed October 2026.
  17. Cloudflare Blog, “PIPEFAIL: How a missing shell option slowed Cloudflare down”, April 5, 2022. Accessed October 2026.
  18. Cloudflare Blog, “Incorrect proxying of 24 hostnames on January 24, 2022”, January 26, 2022. Accessed October 2026.
  19. Cloudflare Blog, “Cloudflare outage on June 21, 2022”, June 21, 2022. Accessed October 2026.
  20. Cloudflare Blog, “Partial Cloudflare outage on October 25, 2022”, October 26, 2022. Accessed October 2026.
  21. Cloudflare Blog, “Cloudflare incident on January 24, 2023”, January 25, 2023. Accessed October 2026.
  22. Cloudflare Blog, “Connection errors in Asia Pacific region on July 9, 2023”, July 11, 2023. Accessed October 2026.
  23. Cloudflare Blog, “Hardening Workers KV”, August 2, 2023. Accessed October 2026.
  24. Cloudflare Blog, “1.1.1.1 lookup failures on October 4, 2023”, October 4, 2023. Accessed October 2026.
  25. Cloudflare Blog, “Cloudflare incident on October 30, 2023”, November 1, 2023. Accessed October 2026.
  26. Cloudflare Blog, “Post mortem on the Cloudflare Control Plane and Analytics Outage”, November 4, 2023. Accessed October 2026.
  27. Cloudflare Blog, “Major data center power failure (again): Cloudflare Code Orange tested”, April 8, 2024. Accessed October 2026.
  28. Cloudflare Blog, “Cloudflare incident on June 20, 2024”, June 26, 2024. Accessed October 2026.
  29. Cloudflare Blog, “Cloudflare 1.1.1.1 incident on June 27, 2024”, July 4, 2024. Accessed October 2026.
  30. Cloudflare Blog, “Cloudflare incident on September 17, 2024”, September 20, 2024. Accessed October 2026.
  31. Cloudflare Blog, “Cloudflare incident on November 14, 2024, resulting in lost logs”, November 26, 2024. Accessed October 2026.
  32. Cloudflare Blog, “Cloudflare incident on February 6, 2025”, February 7, 2025. Accessed October 2026.
  33. Cloudflare Blog, “Cloudflare incident on March 21, 2025”, March 25, 2025. Accessed October 2026.
  34. Cloudflare Blog, “Cloudflare service outage June 12, 2025”, June 12, 2025. Accessed October 2026.
  35. Cloudflare Blog, “Cloudflare 1.1.1.1 Incident on July 14, 2025”, July 15, 2025. Accessed October 2026.
  36. Cloudflare Blog, “Cloudflare incident on August 21, 2025”, August 22, 2025. Accessed October 2026.
  37. Cloudflare Blog, “A deep dive into Cloudflare’s September 12, 2025 dashboard and API outage”, September 13, 2025. Accessed October 2026.
  38. Cloudflare Blog, “Cloudflare outage on November 18, 2025”, November 18, 2025. Accessed October 2026.
  39. Cloudflare Blog, “Cloudflare outage on December 5, 2025”, December 5, 2025. Accessed October 2026.
  40. Cloudflare Blog, “What came first- the CNAME or the A record”, January 14, 2026. Accessed October 2026.
  41. Cloudflare Blog, “Route leak incident on January 22, 2026”, January 23, 2026. Accessed October 2026.
  42. Cloudflare Blog, “Cloudflare outage on February 20, 2026”, February 21, 2026. Accessed October 2026.
  43. Cloudflare Blog, “Code Orange: Fail Small, our resilience plan following recent incidents”, December 19, 2025. Accessed October 2026.
  44. Cloudflare Blog, “Code Orange: Fail Small is complete”, May 1, 2026. Accessed October 2026.

Research library

More original data reports from The Uptime Report. Every report includes its methodology and a free CSV download. Browse all research

Threats and breaches

Infrastructure and uptime

Regulation and disclosure

Workforce and pay

MSP market and spending

Comments

2 responses to “Cloudflare Outage History: 27 of 40 Post-Mortems Trace Back to Cloudflare’s Own Changes”

  1. […] Cloudflare Outage HistoryEvery Cloudflare outage post-mortem […]

  2. […] with DynamoDB global tables could still read and write their replicas in other regions. Our Cloudflare outage history shows the same pattern of self-inflicted changes at another […]

Leave a Reply

Your email address will not be published. Required fields are marked *