O que a observabilidade da Cloudflare precisa antes de um incidente

Toda conta Cloudflare com observabilidade ativada está juntando logs. A maioria desses logs nunca é lida até algo já ter dado errado, momento em que respondem "o que aconteceu", o que é útil, mas um dia atrasado. O valor real da observabilidade é o alerta que soa antes de um cliente abrir um chamado, e esse alerta precisa existir antes do incidente, configurado contra um limiar que alguém pensou com antecedência.

A lacuna entre "temos logs" e "a gente saberia"

Ter Workers Logs e Analytics Engine ativados responde uma pergunta: dá pra reconstruir o que aconteceu, depois do fato. Não responde a pergunta que de fato protege receita: alguém teria percebido enquanto ainda estava acontecendo.

Sinal	Coletado por padrão	Realmente gera alerta
Taxa de erro num endpoint crítico	Sim, nos logs	Quase nunca, a menos que alguém tenha montado
Um pico de respostas 5xx da origem	Sim	Às vezes, se algum limiar já foi configurado
Uma regra de WAF bloqueando tráfego legítimo	Sim, como linha de log	Quase nunca — falsos positivos são silenciosos por design
Um aumento gradual de latência em vários dias	Sim, no Analytics Engine	Raramente; uma tendência gradual não dispara um limiar simples

O padrão nessa tabela não é que faltem dados. Eles estão presentes em cada linha. O que falta é o segundo passo: alguém decidir, com antecedência, qual limiar sobre aquele dado vale a pena pra acordar uma pessoa.

Alertas precisam de ajuste, ou são ignorados

A falha do outro lado é igualmente comum: alertar sobre tudo, o que treina o time a ignorar tudo em um mês. Um alerta que soa todo dia por algo que se resolve sozinho é pior que nenhum alerta, porque queima a credibilidade do alerta que de fato importa.

Construindo isso antes de precisar

Os times que tiram valor real da observabilidade são os que ajustaram os limiares num período tranquilo, com base em como foi de fato o último incidente real, não os que montam um dashboard às pressas durante a própria queda — o mesmo raciocínio por trás de mapear bem um sistema durante uma discovery de duas semanas antes de se comprometer com o que vai ser construído.

Configuramos logging, alertas e analytics como parte da nossa prática de implementação de Cloudflare, dimensionada pro que um time de plantão pequeno realmente consegue agir, não um dashboard por dashboard. Como lidamos com incidentes na nossa própria entrega está nas nossas práticas de segurança.