Lo que la observabilidad de Cloudflare necesita antes de un incidente

Toda cuenta de Cloudflare con observabilidad activada está juntando logs. La mayoría de esos logs nunca se leen hasta que algo ya salió mal, momento en el que responden "qué pasó", lo cual es útil, pero un día tarde. El valor real de la observabilidad es la alerta que suena antes de que un cliente abra un ticket, y esa alerta tiene que existir antes del incidente, configurada contra un umbral que alguien pensó de antemano.

La brecha entre "tenemos logs" y "nos enteraríamos"

Tener Workers Logs y Analytics Engine activados responde una pregunta: podemos reconstruir qué pasó, después de los hechos. No responde la pregunta que realmente protege los ingresos: alguien se habría dado cuenta mientras estaba pasando.

Señal	Se recolecta por defecto	Realmente genera alerta
Tasa de error en un endpoint crítico	Sí, en los logs	Casi nunca, salvo que alguien lo haya armado
Un pico de respuestas 5xx del origen	Sí	A veces, si alguna vez se configuró un umbral
Una regla de WAF bloqueando tráfico legítimo	Sí, como línea de log	Casi nunca — los falsos positivos son silenciosos por diseño
Un aumento gradual de latencia en varios días	Sí, en Analytics Engine	Rara vez; una tendencia gradual no dispara un umbral simple

El patrón en esa tabla no es que falten datos. Están presentes en cada fila. Lo que falta es el segundo paso: que alguien decida, de antemano, qué umbral sobre ese dato vale la pena para despertar a una persona.

Las alertas necesitan ajuste, o se ignoran

La falla del otro lado es igual de común: alertar sobre todo, lo que entrena al equipo a ignorarlo todo en un mes. Una alerta que suena todos los días por algo que se resuelve solo es peor que ninguna alerta, porque quema la credibilidad de la alerta que sí importa.

Construir esto antes de necesitarlo

Los equipos que sacan valor real de la observabilidad son los que ajustaron los umbrales en un período tranquilo, en base a cómo fue realmente el último incidente real, no los que arman un dashboard a las apuradas durante la caída misma — el mismo razonamiento detrás de mapear bien un sistema durante un discovery de dos semanas antes de comprometerse con qué se construye.

Configuramos logging, alertas y analítica como parte de nuestra práctica de implementación de Cloudflare, dimensionada a lo que un equipo de guardia chico realmente puede accionar, no un dashboard porque sí. Cómo manejamos incidentes en nuestra propia entrega está en nuestras prácticas de seguridad.