CLOUDFLARE

A Cloudflare informou que, entre 01h06 e 01h54 UTC de 23 de agosto, alguns clientes podem ter enfrentado mais respostas 5xx e timeouts no tráfego entre origens na América do Norte e seu data center de Singapura. O incidente foi encerrado, mas a descrição pública específica apareceu depois do fim do intervalo de impacto.

A Cloudflare levou 8 minutos e 36 segundos para anunciar uma correção para um problema de desempenho de rede na Ásia-Pacífico. O aviso continuou em monitoramento e não informou local, produto ou sintoma, deixando para cada cliente a tarefa de separar a resposta da borda, o caminho de rede e o comportamento da origem.

Dois incidentes de Workers encerrados em 4 de agosto atingiram pontos diferentes da operação. Um objeto global `Temporal`, exposto sem intenção, informava 1970 sem gerar erro. Em outro caso, uma asserção bloqueava a implantação com `nodejs_compat` e data de compatibilidade a partir de 4 de agosto. A Cloudflare não disse que havia uma causa comum. O que os une é a necessidade de testar o contrato completo da plataforma: a configuração aceita antes do deploy e o comportamento entregue depois dele.

Cloudflare encerrou em 3 de agosto um incidente de aproximadamente uma hora e 51 minutos no Workers Builds. A cronologia mostra por que a continuidade de um serviço não pode ser medida apenas pela versão que já está no ar: às 15h38 UTC, os builds haviam parado de falhar, mas os usuários ainda podiam enfrentar atrasos. Nesse intervalo, uma aplicação poderia continuar respondendo enquanto sua equipe permanecia sem uma via previsível para publicar a próxima correção. O registro não informa causa, quantidade de clientes nem impacto no runtime, por isso a análise deve permanecer no componente de build indicado.

A Cloudflare resolveu uma ocorrência de Gateway em que clientes com IPv4 de saída dedicada vinculada a Londres podiam ficar sem acesso à internet pública. A janela pública durou 2 horas, 17 minutos e 50 segundos, incluindo quase 13 minutos de monitoramento depois da aplicação da correção. O aviso não quantificou a população atingida nem revelou a causa. Para equipes de continuidade, a lição não é tratar o episódio como pane londrina geral, mas reconhecer que um caminho alternativo só funciona quando preserva também a identidade de origem aceita pelos destinos.

Em 27 de junho de 2024, dois eventos de roteamento distintos afetaram a alcançabilidade do resolvedor público 1.1.1.1 da Cloudflare. Um anúncio indevido do prefixo específico 1.1.1.1/32 e um vazamento separado do prefixo 1.1.1.0/24 expuseram limites diferentes de filtragem, validação de origem, controle de exportação e blackholing remoto. O episódio mostra por que registros de alocação e ROAs são evidências importantes, mas não substituem políticas executadas nos roteadores nem determinam, sozinhos, quem podia impedir, detectar, conter e retirar uma rota problemática.

A ocorrência de 22 de janeiro de 2026 mostra por que uma alteração pequena e sintaticamente válida não basta para demonstrar a segurança de uma política BGP: é preciso provar, em cada camada, quais rotas o roteador passou a aceitar para exportação, para quais vizinhos e sob quais relações operacionais.

O incidente de 20 de fevereiro expôs um problema fundamental da infraestrutura de rede: documentos de autoridade sobre endereços IP não bastam quando registros de serviço, intenção de anúncio BGP, configuração efetivamente implantada e observação externa deixam de representar o mesmo estado.

Cloudflare перешла от расследования сетевой производительности в Азиатско-Тихоокеанском регионе к мониторингу исправления за 8 минут 36 секунд. Публичная запись осталась открытой и не назвала место, продукт, симптом или масштаб, поэтому минимальный тест закрытия лежит в телеметрии каждого клиентского пути.

Cloudflare meldete ein Netzwerkleistungsproblem im asiatisch-pazifischen Raum und acht Minuten 36 Sekunden später einen umgesetzten Fix. Trotzdem wechselte die verknüpfte Network-Komponente in beiden Einträgen nur von operativ zu operativ. Aggregierter Komponentenstatus und Vorfallnarrativ messen damit unterschiedliche Dinge.

انتقلت Cloudflare من التحقيق في مشكلة أداء شبكي في آسيا والمحيط الهادئ إلى مراقبة إصلاح خلال 8 دقائق و36 ثانية. لكن السجل بقي مفتوحاً ولم يحدد موقعاً أو منتجاً أو عرضاً أو حجماً للتأثير، لذلك لا تمنح مرحلة المراقبة المشغلين دليلاً على تعافي كل مسار.

A Cloudflare levou 8 minutos e 36 segundos para anunciar uma correção para um problema de desempenho de rede na Ásia-Pacífico. O aviso continuou em monitoramento e não informou local, produto ou sintoma, deixando para cada cliente a tarefa de separar a resposta da borda, o caminho de rede e o comportamento da origem.

Cloudflareはアジア太平洋のネットワーク性能問題を公表してから8分36秒後に修正を実施した。しかし事象は監視中のままで、場所、製品、症状、影響母数は示されていない。運用者が確認すべき単位は地域全体ではなく、利用者からCloudflare拠点、オリジンまでの経路である。

Cloudflare在发布亚太地区网络性能事件8分36秒后称已实施修复，但截至事实截止点仍未解决。公开记录没有城市、产品、症状或客户分母，运营方只能把供应商的UTC时间线与自身路径证据对齐，不能用“亚太”替代影响范围。

Cloudflare informó de un problema de rendimiento de red en Asia-Pacífico y anunció una corrección 8 minutos y 36 segundos después. Sin embargo, el impacto estructurado siguió en `none` y el componente Network pasó de operativo a operativo: la narración registra un incidente que los campos de estado no cuantifican.

Cloudflare a annoncé un correctif huit minutes et 36 secondes après l'ouverture d'un incident de performance réseau en Asie-Pacifique. Mais l'avis est resté en surveillance, sans ville, produit, symptôme ni population affectée : l'étiquette régionale ne peut donc pas servir de dénominateur.

Cloudflare moved a broadly labelled Asia-Pacific network-performance incident from investigation to monitoring in 8 minutes 36 seconds. The record remained open more than 86 minutes later and named no location, product, symptom or customer denominator, so the fix timestamp cannot double as a customer-recovery timestamp.

Cloudflare introduced AI Labyrinth on 19 March 2025 as an opt-in defense for crawlers that ignored no-crawl directives. Instead of only rejecting a request, the service could expose suspected bots to linked, AI-generated decoy pages. The design joined deterrence and detection: waste an unwanted crawler's resources, then treat its decision to follow bot-only links as another signal. But Cloudflare's launch evidence described a mechanism, not an independently measured success rate.

On 1 July 2025, Cloudflare announced a permission-based approach to AI crawling for websites using its network. The change was not a universal paywall and did not prove that every crawler would comply. It was a set of distinct controls: an upfront choice for newly onboarded domains, managed `robots.txt` signals, edge-enforced blocking options, and a private-beta Pay Per Crawl experiment. Reading those layers separately shows what changed at the web edge—and what remained unproven.

Cloudflare schloss am 4. August zwei getrennte Workers-Störungen. In der Laufzeitumgebung erschien ein unbeabsichtigtes globales `Temporal`-Objekt, dessen Uhr 1970 meldete. Im Deployment-Pfad wies eine Assertion die Kombination aus `nodejs_compat` und einem neuen Kompatibilitätsdatum zurück. Cloudflare nannte keine gemeinsame Ursache. Gemeinsam zeigen die Fälle dennoch, dass eine Plattform sowohl die Semantik einer sichtbaren Fähigkeit als auch die Zulässigkeit einer Lieferkonfiguration als Produktionsvertrag behandeln muss.

أغلقت Cloudflare في 4 أغسطس حادثتين مختلفتين في Workers. في الأولى ظهر كائن `Temporal` عام من دون قصد، وكانت ساعته تعيد عام 1970. وفي الثانية رفضت بوابة النشر إعداداً يجمع `nodejs_compat` مع تاريخ توافق يبدأ من 4 أغسطس. لم تقل الشركة إن السبب واحد. لكن الحادثتين توضحان أن السيطرة في الحوسبة عديمة الخوادم موزعة على حدّين: ما تسمح المنصة بنشره، وما تعطيه للكود من معنى عند التشغيل.

Dois incidentes de Workers encerrados em 4 de agosto atingiram pontos diferentes da operação. Um objeto global `Temporal`, exposto sem intenção, informava 1970 sem gerar erro. Em outro caso, uma asserção bloqueava a implantação com `nodejs_compat` e data de compatibilidade a partir de 4 de agosto. A Cloudflare não disse que havia uma causa comum. O que os une é a necessidade de testar o contrato completo da plataforma: a configuração aceita antes do deploy e o comportamento entregue depois dele.

Cloudflareは8月4日、Workersに関する二つの独立したインシデントを解決した。一方では、意図せず公開された`Temporal`の時刻が1970年を示した。もう一方では、`nodejs_compat`と新しい互換日付の組み合わせが配備時のアサーションに拒否された。共通原因は公表されていない。重要なのは、コードが動き始める前の許可と、動いた後に得る意味の両方が、プラットフォームのリリースによって変わり得ることである。

Cloudflare在8月4日关闭了两起彼此独立的Workers事件。第一起让本不该出现的`Temporal`全局对象进入运行时，而且它把当前时间报告为1970年；第二起则在部署入口拒绝了带有`nodejs_compat`且兼容日期不早于8月4日的配置。Cloudflare没有说明两者同源。它们共同暴露的是一条更长的控制链：平台既决定代码能“看见”什么，也决定代码能否进入生产。

Cloudflare cerró el 4 de agosto dos incidentes distintos de Workers. Uno alteró silenciosamente el significado de una capacidad en tiempo de ejecución: `Temporal.Now` devolvía 1970. El otro impidió desplegar una combinación concreta de `nodejs_compat` y fecha de compatibilidad. No hay base para atribuirles una causa común. Sí la hay para revisar la cadena completa, desde la validación de una configuración hasta la semántica que recibe el código una vez desplegado.

Deux incidents Workers, clos le 4 août, ont rompu deux promesses différentes. Dans le moteur d’exécution, un objet `Temporal` apparu sans être prévu donnait l’heure du 1er janvier 1970. Dans le plan de déploiement, une assertion refusait une combinaison récente de date de compatibilité et de drapeau `nodejs_compat`. Cloudflare n’a pas relié les causes. Leur proximité montre néanmoins qu’une plateforme doit vérifier la sémantique qu’elle expose aussi rigoureusement que les configurations qu’elle accepte.

Cloudflare closed two separate Workers incidents on 4 August: a runtime exposed an unintended `Temporal` global whose clock reported 1970, while a deployment assertion rejected Workers using `nodejs_compat` with a new compatibility date. Neither was described as a platform-wide outage, and Cloudflare did not give them a common cause. Together, however, they show why a release contract must cover both what an application detects at runtime and what the control plane permits at deployment.

Cloudflare erklärte am 3. August einen Vorfall bei Workers Builds nach rund einer Stunde und 51 Minuten für behoben. Der aufschlussreichste Zeitpunkt lag jedoch 34 Minuten vor dem Ende: Um 15:38 Uhr UTC schlugen Builds nach Angaben des Unternehmens nicht mehr fehl, konnten sich aber weiterhin verzögern. Damit wurde aus einem Fehlerproblem ein Durchsatzproblem. Wer digitale Lieferketten steuert, muss diese Zustände getrennt prüfen—vom Quellstand über den Build und das Artefakt bis zur tatsächlich laufenden Version.

أغلقت Cloudflare في 3 أغسطس حادثة استمرت نحو ساعة و51 دقيقة في Workers Builds. لكن لحظة الاستعادة الأهم سبقت الإغلاق: عند 15:38 بالتوقيت العالمي قالت الشركة إن عمليات البناء لم تعد تفشل، مع بقاء احتمال التأخير. هذا الفاصل يضع الإدارة أمام سؤالين مختلفين: هل النسخة المنشورة تعمل، وهل تستطيع المؤسسة بناء التغيير التالي ونشره بأمان؟ لا تكشف الصفحة سبب العطل أو عدد العملاء أو أثره على وقت التشغيل، ولذلك يجب إبقاء الاستنتاج ضمن مسار البناء المسمّى وعدم تحويله إلى ادعاء بانقطاع شامل.

Cloudflare encerrou em 3 de agosto um incidente de aproximadamente uma hora e 51 minutos no Workers Builds. A cronologia mostra por que a continuidade de um serviço não pode ser medida apenas pela versão que já está no ar: às 15h38 UTC, os builds haviam parado de falhar, mas os usuários ainda podiam enfrentar atrasos. Nesse intervalo, uma aplicação poderia continuar respondendo enquanto sua equipe permanecia sem uma via previsível para publicar a próxima correção. O registro não informa causa, quantidade de clientes nem impacto no runtime, por isso a análise deve permanecer no componente de build indicado.

Cloudflareは8月3日、Workers Buildsで発生したインシデントを約1時間51分後に解決済みとした。運用上の核心は終了時刻だけではない。15時38分（UTC）にビルドの失敗は止まったものの、ユーザーにはなお遅延が生じ得ると説明され、その後に監視、解決という段階が続いた。ビルド経路の復旧は一つの緑色表示ではなく、エラー停止、待機仕事の処理、成果物の確認、デプロイ結果の照合というチェックポイントで判断すべきである。

Cloudflare在8月3日用约1小时51分钟处置了一次Workers Builds事件。最值得关注的不是最终“已解决”，而是15:38 UTC的中间状态：构建已经不再失败，用户却仍可能遇到延迟。它把两种经常被混为一谈的可用性分开了——上一版本能否继续运行，以及团队能否把下一次修复可靠地送上生产。状态页没有披露根因、客户数量和生产运行影响，因此这是一场范围明确的构建链路事件，不应被扩写成全球Workers全面中断。

Cloudflare declaró resuelto el 3 de agosto un incidente de una hora y 51 minutos en Workers Builds. La recuperación no fue instantánea: a las 15:38 UTC las compilaciones ya no fallaban, aunque los usuarios todavía podían sufrir demoras; después llegó la fase de monitorización y solo a las 16:12 se cerró el incidente. Esa escalera importa para el control de versiones: restablecer la capacidad de compilar no demuestra por sí solo que cada reintento produjo el artefacto correcto ni que cada despliegue pendiente terminó.

Le 3 août, Cloudflare a suivi pendant une heure et 51 minutes un incident touchant Workers Builds. Sa chronologie évite un raccourci fréquent : à 15 h 38 UTC, les builds ne se terminaient plus en échec, mais des retards pouvaient encore affecter les utilisateurs. La disparition d’une erreur n’est donc pas la preuve que la file d’attente a retrouvé son débit normal. Faute de cause, de volumes et de mesure de l’exécution en production, l’événement doit être lu comme un problème circonscrit à la chaîne de changement, et non comme une panne mondiale de Workers.

Cloudflare marked an August 3 Workers Builds incident resolved after one hour and 51 minutes. The revealing moment came earlier: at 15:38 UTC, builds were no longer failing, yet users could still encounter delays. That interval separates two kinds of availability—keeping an existing deployment in place and retaining the ability to compile and release the next one. Cloudflare did not disclose a root cause, customer count or runtime impact, so the event supports a precise lesson about change capacity, not a claim of a global Workers outage.

Cloudflare hat eine Gateway-Störung behoben, bei der Kunden mit in London verankerten dedizierten IPv4-Egress-Adressen möglicherweise das öffentliche Internet nicht erreichen konnten. Der öffentliche Vorgang dauerte 2 Stunden, 17 Minuten und 50 Sekunden. Er benennt die betroffene Komponente und die Statusfolge, aber weder Ursache noch Größenordnung. Für die technische Bewertung ist deshalb nicht „London ist ausgefallen“ der richtige Satz. Entscheidend ist, dass eine kontrollierte Ausgangsidentität nur so verfügbar ist wie der Providerpfad, der sie trägt.

أنهت Cloudflare حادثة في Gateway كان من الممكن أن تمنع عملاء يستخدمون عناوين IPv4 مخصصة للخروج ومربوطة بلندن من الوصول إلى الإنترنت العام. استغرقت دورة الحالة العلنية ساعتين و17 دقيقة و50 ثانية، وانتقلت من التحقيق إلى تحديد المشكلة ثم تنفيذ إصلاح ومراقبته وإعلان الحل. تكشف هذه السلسلة ما فعلته الجهة المشغلة على مستوى الحالة، لكنها لا تكشف السبب أو حجم المجموعة المتأثرة أو أثرها التجاري. لذلك تصبح المساءلة هنا ممارسة في الفصل بين الإفصاح المؤكد والفراغ الذي لا يجوز ملؤه بالتخمين.

A Cloudflare resolveu uma ocorrência de Gateway em que clientes com IPv4 de saída dedicada vinculada a Londres podiam ficar sem acesso à internet pública. A janela pública durou 2 horas, 17 minutos e 50 segundos, incluindo quase 13 minutos de monitoramento depois da aplicação da correção. O aviso não quantificou a população atingida nem revelou a causa. Para equipes de continuidade, a lição não é tratar o episódio como pane londrina geral, mas reconhecer que um caminho alternativo só funciona quando preserva também a identidade de origem aceita pelos destinos.

Cloudflareは、ロンドンにひもづく専用IPv4 Egress IPを使う顧客が公共インターネットへ到達できない可能性があるとして、Gatewayのインシデントを開設した。2時間17分50秒後に解決済みとなったが、公開記録が実際に証明するのは、調査、特定、修正の実装、監視、解決という状態遷移である。原因や顧客数、トラフィック比率、顧客ごとの復旧時刻は示されていない。運用ステータスを正しく読むには、各段階が示す証拠と示さない証拠を分ける必要がある。

Cloudflare用2小时17分50秒处理完一宗Gateway事件：使用归属伦敦的专用IPv4出口地址的客户，可能无法访问公共互联网。固定出口IP常被当成安全白名单里的静态标识，但它并非脱离网络路径而独立存在。地址要通过提供商的网关、路由和区域服务才能发挥作用。本次公开记录没有给出原因和影响分母，却清楚展示了“稳定身份”如何同时形成一个狭窄而真实的故障域。

Cloudflare resolvió un incidente de Gateway que podía impedir el acceso a Internet público a clientes con direcciones IPv4 de salida dedicadas alojadas en Londres. El caso duró 2 horas, 17 minutos y 50 segundos desde su creación hasta el cierre. La precisión del aviso está en la cohorte de enrutamiento, no en su tamaño: no ofrece número de cuentas, tráfico afectado ni causa. Por eso, el análisis debe seguir la ruta nombrada y no convertirla en una interrupción de toda la ciudad o de toda la plataforma.

Cloudflare a clos après 2 heures 17 minutes et 50 secondes un incident touchant l’accès à Internet public de clients utilisant des adresses IPv4 de sortie dédiées rattachées à Londres. Le journal public distingue cinq étapes : enquête, identification, mise en œuvre d’un correctif, surveillance, puis résolution. Cette précision rend possible une lecture rigoureuse de la reprise. Elle ne fournit toutefois ni cause, ni volume de trafic, ni nombre de clients, ni preuve que chaque parcours client a récupéré au même instant.

Cloudflare restored Gateway service after a two-hour incident in which customers using dedicated IPv4 egress addresses homed in London could have been unable to reach the public Internet. The public record is precise about the affected path and the five operational states, but sparse about scale and cause. That combination matters. A dedicated egress address gives an organisation a durable identity for allowlists and policy, yet it also concentrates outbound traffic on a provider-managed dependency whose failure can interrupt destinations that are otherwise healthy.

Em 27 de junho de 2024, dois eventos de roteamento distintos afetaram a alcançabilidade do resolvedor público 1.1.1.1 da Cloudflare. Um anúncio indevido do prefixo específico 1.1.1.1/32 e um vazamento separado do prefixo 1.1.1.0/24 expuseram limites diferentes de filtragem, validação de origem, controle de exportação e blackholing remoto. O episódio mostra por que registros de alocação e ROAs são evidências importantes, mas não substituem políticas executadas nos roteadores nem determinam, sozinhos, quem podia impedir, detectar, conter e retirar uma rota problemática.

A ocorrência de 22 de janeiro de 2026 mostra por que uma alteração pequena e sintaticamente válida não basta para demonstrar a segurança de uma política BGP: é preciso provar, em cada camada, quais rotas o roteador passou a aceitar para exportação, para quais vizinhos e sob quais relações operacionais.

O incidente de 20 de fevereiro expôs um problema fundamental da infraestrutura de rede: documentos de autoridade sobre endereços IP não bastam quando registros de serviço, intenção de anúncio BGP, configuração efetivamente implantada e observação externa deixam de representar o mesmo estado.

A campanha de março de 2013 mostrou como recursão DNS exposta, falsificação de endereços de origem e caminhos compartilhados de interconexão podem converter falhas locais aparentemente pequenas em um custo externo de grande escala. Responsabilizar exige identificar quem controlava cada etapa executável, o que foi observado em cada ponto da rede e se o reparo foi comprovado.

Cloudflare eröffnete am 31. Juli um 11:51:07 UTC einen geringfügigen Vorfall, der zunächst Analytics, Dashboard und zugehörige APIs betraf. Später kamen Pages- und Workers-Builds hinzu. Um 12:43:57 ging eine Korrektur in die Überwachung, um 13:01:59 wurde der Vorfall beendet. Laut Cloudflare blieben die Auslieferung zwischengespeicherter Dateien über das CDN und andere Sicherheitsfunktionen am Edge unbeeinträchtigt. Damit fiel nicht das gesamte Netz aus, sondern ein Teil der Beobachtungs-, Verwaltungs- und Bereitstellungsebene.

سجلت Cloudflare في 31 يوليو عند 11:51:07 بالتوقيت العالمي حادثا طفيفا بدأ في Analytics ولوحة التحكم وواجهات مرتبطة، ثم امتد إلى بناء Pages وWorkers. دخل الإصلاح مرحلة المراقبة عند 12:43:57 وأغلق الحادث عند 13:01:59. وأكدت الشركة أن تقديم الملفات المخزنة مؤقتا عبر شبكة CDN وميزات الحماية الأخرى عند الحافة لم يتأثر. كان الخلل في إدارة الخدمات ونشر التغييرات، لا انقطاعا شاملا للحافة.

A Cloudflare registrou às 11:51:07 UTC de 31 de julho um incidente menor que começou em Analytics, Dashboard e APIs relacionadas e depois alcançou builds de Pages e Workers. Uma correção entrou em monitoramento às 12:43:57, e o caso foi encerrado às 13:01:59. Segundo a empresa, a entrega de arquivos em cache pelo CDN e outras funções de segurança na borda não foram afetadas. O episódio separou a disponibilidade pública de um site da capacidade de observá-lo, configurá-lo e publicar alterações.

Cloudflareは7月31日11時51分07秒（UTC）、AnalyticsやDashboard、関連APIに関する軽微な障害を記録した。その後、PagesとWorkersのビルドにも影響が広がり、12時43分57秒に修正の監視へ移行、13時01分59秒に解消した。キャッシュ済みファイルのCDN配信とその他のEdgeセキュリティ機能には影響がなかったと同社は説明している。公開サイトが動く一方で、運用者が観測・変更・再ビルドしにくくなる制御面の障害だった。

Cloudflare在7月31日11:51:07 UTC记录了一起轻微事件，最初涉及Analytics、Dashboard及相关API，随后扩展到Pages和Worker构建。修复在12:43:57进入监控，13:01:59宣告解决。Cloudflare明确表示，CDN缓存文件交付和其他边缘安全功能未受影响。这次事件揭示的是“站点仍可访问，但管理、观测和发布变更受阻”的分层故障，而非整个Cloudflare网络中断。

Un incidente menor de Cloudflare comenzó el 31 de julio a las 11:51:07 UTC y afectó primero a Analytics, el Dashboard y API relacionadas. Después alcanzó a las compilaciones de Pages y Workers. La empresa aplicó una corrección y pasó a vigilancia a las 12:43:57; cerró el caso a las 13:01:59. Cloudflare afirmó que la entrega de archivos en caché por el CDN y otras funciones de seguridad en el borde no se vieron afectadas. Fue una interrupción del plano de control y de parte del flujo de despliegue, no una caída total de la red.

Cloudflare a ouvert le 31 juillet à 11 h 51 min 07 s UTC un incident mineur touchant d’abord Analytics, le Dashboard et des API associées. Les répercussions ont ensuite été étendues aux compilations Pages et Workers. Un correctif est passé en surveillance à 12 h 43 min 57 s, avant une résolution à 13 h 01 min 59 s. Cloudflare a précisé que la distribution des fichiers en cache par son CDN et les autres fonctions de sécurité en périphérie n’étaient pas affectées. L’incident a donc touché la capacité d’administrer et de livrer des changements, pas l’ensemble du réseau.

Cloudflare recorded a minor incident at 11:51:07 UTC on 31 July, initially warning that Dashboard and related-API requests might fail while Analytics was degraded. The event later expanded to Pages and Worker builds, entered monitoring at 12:43:57 and was marked resolved at 13:01:59. Cloudflare explicitly said cached-file delivery through its CDN and other Edge security features were unaffected. That separation matters: customers lost reliable access to management and build functions without evidence that ordinary cached traffic stopped flowing.