Resumo
- A Cloudflare abriu o incidente pgcdxsjxkl0q às 11:51:07 UTC com impacto menor e status de investigação.
- No corte fixo das 11:53:12, Analytics estava degradado e ainda não havia atualização de recuperação.
- O primeiro aviso apontou possíveis falhas ou erros no Dashboard e em APIs relacionadas.
- A empresa excluiu do impacto a entrega de cache pelo CDN e outras funções de segurança no Edge.
- Atualizações posteriores acrescentaram API, Dashboard, Pages e builds de Workers; o monitoramento começou às 12:43:57.
- O incidente foi resolvido às 13:01:59 sem causa, número de clientes ou divisão geográfica.
O relógio do relatório parou antes da solução
A janela deste boletim terminou dois minutos e cinco segundos após o início do incidente. Naquele instante, o registro oficial sustentava apenas investigação e desempenho degradado do Analytics.
Correção e encerramento são fatos posteriores e aparecem com seus próprios horários. Projetá-los sobre o corte apagaria a incerteza real do momento.
Uma linha do tempo fiel mede tanto o serviço quanto a qualidade da comunicação.
O plano de dados permaneceu distinto do controle
A Cloudflare informou que arquivos em cache continuavam sendo servidos pelo CDN e que outras funções de segurança do Edge não sofreram impacto. Já pedidos no Dashboard e nas APIs relacionadas poderiam falhar.
Assim, um cliente podia manter a página pública no ar e, simultaneamente, perder capacidade de configuração e observação.
O registro não justifica dizer que DNS, CDN ou toda a segurança da rede ficaram indisponíveis.
Cada ampliação teve um horário
Às 12:25:44, API e Dashboard passaram a constar como degradados. Às 12:37:35, a empresa incluiu builds de Pages e Workers.
Não há horário retroativo de início para essas duas últimas funções. O que se sabe é quando o novo alcance foi comunicado.
Preservar essa diferença evita atribuir setenta minutos completos a todos os componentes.
Um build parado cobra seu preço na próxima ação
Uma versão já implantada pode continuar servindo usuários enquanto novas compilações falham. O problema aparece na hora de lançar uma correção, reverter uma mudança ou responder a uma falha de segurança.
Por isso, o impacto depende da agenda operacional de cada cliente. Sites estáveis e equipes em emergência não enfrentam o mesmo risco.
Não foram divulgados taxa de erros, quantidade de builds ou perfil de contas atingidas.
O verde voltou sem uma explicação técnica
A correção entrou em monitoramento às 12:43:57. Houve nova mensagem de observação às 12:46:20, e a resolução veio às 13:01:59.
Analytics, API, Dashboard, Pages e Workers voltaram ao estado operacional. O texto final não informa a causa nem solicita medidas dos clientes.
Encerrar o incidente confirma recuperação, mas não entrega análise causal.
Continuidade também precisa de um modo sem painel
Configuração versionada, cópias de métricas essenciais fora do Dashboard e regras sobre quais mudanças podem esperar reduzem a exposição imediata.
O plano de resposta deve separar falha de entrega no Edge de falha administrativa. Mover tráfego saudável porque o painel está indisponível pode criar uma segunda interrupção.
Um pós-incidente com causa, erros por minuto, builds afetados e eventual recomposição de dados completaria a avaliação. Até lá, a afirmação sustentada é limitada: houve cerca de setenta minutos de degradação no controle e na construção, enquanto a Cloudflare declarou preservadas a entrega em cache e outras funções de segurança na borda.