Fatiga de alertas: 82 correos en un día de mi monitor de seguridad

¿Cuántas alertas debería enviar un monitor de seguridad que lee una sola persona? Según mis números, alrededor de un correo al día, más el raro que me pide hacer algo. El 1 de noviembre mi monitor pasó 74 correos al servicio de correo entre la medianoche y las 13:32, hora del Pacífico: 55 por bloqueos que ya había hecho, 16 alertas críticas, dos alertas horarias de volumen y una del escáner de mi Mac.¹² Mi lectura aquella tarde fue que todos describían escaneos rutinarios que el borde ya había detenido;³ en el caso de las avalanchas críticas, la sección 6 muestra que esa lectura fue demasiado generosa. La solución fue una política, no un umbral: un resumen diario que hace también de latido (heartbeat), los bloqueos al chat en lugar del correo, una alerta crítica incorporada al resumen cuando el borde ya se encargó de ella y el desenlace escrito en cada alerta crítica de la nube. Al día siguiente, un escáner disparó cuatro alertas críticas en menos de seis minutos en mis sitios, y mi monitor no envió ni un correo por ello.⁴ Ese día aún produjo 19 correos, no uno, y el motivo es la parte más útil de la historia.⁵

Soy el único lector del correo de mi monitor. Cuando la bandeja de entrada marcó 74, me pregunté si aquello era rutina o algo real, y la respuesta honesta fue que el monitor no podía decírmelo con los asuntos, porque todos decían lo mismo a distinto volumen.¹ Un monitor al que su único lector deja de leer ha dejado de monitorear, por mucho que sus detectores sigan detectando. Lo que sigue es el conteo, la política que lo reemplazó, un caso de prueba y los tres puntos donde la versión limpia de la historia se rompe.

TL;DR

• 74 correos a las 13:32, 82 a la medianoche. Mi propia tabla y el conteo derivado de los logs coinciden en 74 antes de que me quejara (55 por bloqueo, 16 críticos, dos horarios, uno local); el 1 de noviembre completo sumó 81 registrados más un resumen que envié a mano.¹²⁵
• 22 de los 74 no están probados. Salieron de código que registraba «sent» (enviado) sin revisar la respuesta del servicio de correo, así que el log prueba que se intentó un traspaso, no que llegara un mensaje.²⁶
• La literatura ya tenía la regla. El libro de SRE de Google admite tres salidas (alertas, tickets y registro), dice «Every page should be actionable» (toda página debe ser accionable) y llama a las alertas por correo «alert spam»; la alerta de The Joint Commission (el organismo estadounidense que acredita hospitales) cita una estimación según la cual «between 85 and 99 percent of alarm signals do not require clinical intervention» (entre el 85 y el 99 por ciento de las señales de alarma no requieren intervención clínica).⁷⁸⁹¹⁰
• El caso de prueba funcionó. El 2 de noviembre, una dirección de un proveedor de hosting neerlandés levantó cuatro alertas críticas en 5 minutos y 51 segundos en mis sitios; el monitor la bloqueó una vez, publicó el bloqueo en el chat, incorporó cada crítica al resumen y no envió ningún correo.⁴¹¹¹²
• El día siguiente aún envió 19, no uno. Catorce eran alertas críticas de avalancha de WAF en las que algunos eventos no tenían bloqueo ni desafío registrado, y sus asuntos decían «WAF blocks» (bloqueos de WAF) aunque el borde no hubiera bloqueado ninguno de los eventos (dos veces ese día; la noche anterior, uno dijo «104 WAF blocks» cuando el borde no había bloqueado ni desafiado nada); mi primera reformulación, el mismo día en que se hizo el conteo, todavía mezclaba dos conteos en una línea, y la revisión de este post lo detectó.⁵¹³¹⁴
• Dos señales estaban equivocadas. Una verificación de firma de código en mi Mac llamó minero de criptomonedas sin firmar al propio daemon de Spotlight de Apple, y el «RUNS SHORT 162/207» (faltan ejecuciones) del resumen resultó ser en parte sueño de la Mac, en parte una cadencia real más lenta y en parte, por los tiempos, tres ejecuciones terminadas por el watchdog.¹⁵¹⁶¹⁷
• Qué cambió: un resumen al día lleva el latido, cada bloqueo y el desenlace de cada alerta crítica de la nube, mientras que solo una crítica que no cubre ninguna de las dos incorporaciones, la alerta horaria de volumen y el escáner local siguen enviando correo de inmediato; los 82 correos del 1 de noviembre pasaron a 19 el 2 de noviembre.¹⁸⁵

1. La bandeja de entrada el 1 de noviembre

A las 13:32, hora del Pacífico, del 1 de noviembre le escribí a la sesión de agente que opera mi infraestructura: los correos del monitor estaban llenando de spam mi bandeja; ¿había algo que cambiar?, ¿eran cosas rutinarias o amenazas reales?¹ La tabla que llevé aquella tarde contaba 74 correos desde la medianoche, por remitente: 55 avisos de uno por bloqueo, 16 alertas críticas, dos alertas horarias de volumen y una crítica del escáner de mi Mac.¹

El conteo descansa en una regla, así que la dejo aquí antes de los números. Un correo, para este post, es una línea en el log del monitor que registra un traspaso al servicio de correo. Un script recorrió los seis archivos de log del 31 de octubre al 2 de noviembre y clasificó cada una de esas líneas por flujo y por resultado.⁵ Cortado a las 13:32, el script coincide con mi tabla flujo por flujo: 55, 16, dos y uno, en total 74.² El día local completo, hasta la medianoche, sumó 81 correos registrados (55 por bloqueo, 22 críticos, tres horarios, uno local), más un resumen que envié a mano a las 13:48, que no tiene línea de envío en el log del monitor, para un total de 82.⁵¹

Dentro de esa coincidencia importan dos detalles. Mi tabla decía «9 before the fold went live at 00:30 PT; the 7 after» (9 antes de que la incorporación entrara en vigor a las 00:30 PT; los 7 después) para las críticas; el log tiene 11 líneas críticas de «sent» antes de las 00:30 y cinco después, y la primera crítica incorporada a un aviso de bloqueo aparece a las 00:54:43, después de que el cambio de la incorporación llegara a las 00:46 PDT, no a las 00:30 que nombraba mi tabla.²¹⁸ Los totales coinciden; el reparto que anoté a mano se equivocaba por dos. El segundo detalle es mayor. De los 74, 22 (10 por bloqueo, 11 críticos, uno horario) vinieron de remitentes que desechaban la respuesta del servicio de correo y después registraban «sent» sin importar lo que hubiera vuelto.²⁶ Una corrección a las 01:04 PDT de esa mañana, antes de que se atrasaran los relojes, hizo que los remitentes de la mitad en la nube registraran el estado HTTP del servicio y dijeran «sent» solo ante un 2xx; el remitente del escáner local escribe una línea escueta «Critical email sent» (correo crítico enviado), y solo cuando la solicitud no lanzó ningún error.⁶ Las 22 líneas anteriores prueban que el monitor lo intentó; no prueban que el servicio de correo aceptara nada. Mi log del 31 de octubre juzgaba que los correos de la nube «most likely were» (muy probablemente fueron) entregados, lo cual es una suposición razonable y sigue siendo una suposición.¹⁹

Incluso un 2xx prueba menos de lo que sugiere la palabra «sent». La documentación de Resend define su evento email.sent como «Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server» (ocurre cuando la solicitud a la API tuvo éxito; Resend intentará entregar el mensaje al servidor de correo del destinatario), y enumera la entrega como un evento aparte y posterior.²⁰ La propia llamada de envío responde con un id.²¹ Cada conteo que sigue es un conteo de traspasos que el servicio de correo aceptó o, para los 22 del 1 de noviembre y los 10 del 31 de octubre, 32 en total, de traspasos que el monitor intentó.⁵ Ninguno es un conteo de mensajes que yo haya leído.

Por horas, el día parece un acantilado seguido de una meseta.

1 de noviembre, hora local: correos por hora frente a alertas que no se convirtieron en correo, con el cambio de política de las 13:50 marcado.²²

La primera hora llevó 22 correos, todos del código sin verificar (10 por bloqueo, 11 críticos, uno horario).²² A partir de ahí, los avisos por bloqueo corrieron a razón de uno a cinco por hora, porque el borde seguía bloqueando escáneres y cada bloqueo me escribía una carta. El último correo por bloqueo salió a las 13:25:57; el primer aviso por bloqueo incorporado al resumen aparece a las 14:20:35.²² Después del cambio de las 13:50, los correos bajan a entre cero y dos por hora, mientras las alertas incorporadas y suprimidas suben hasta 23 por hora.²² El tráfico no bajó. Los correos sí.

El día anterior es una mala línea base. Mi log del 1 de noviembre dice «Yesterday had 10» (ayer hubo 10), y el script coincide, pero el log del 31 de octubre empieza a las 22:31, la noche en que volví a armar el monitor, así que esos 10 correos cubren 89 minutos.¹⁵ Según mi lectura, los 74 midieron al detector trabajando durante un día completo de ruido de fondo de internet, no un cambio en lo que hacían los escáneres.

2. Para qué servían las alertas

El monitor tiene dos mitades. La mitad en la nube está programada para ejecutarse en mi Mac cada cinco minutos y le pide a Cloudflare los eventos de firewall y los conteos agrupados de solicitudes de cada una de mis zonas: qué direcciones tocaron qué rutas, con qué frecuencia y qué acción tomó el borde en cada evento.¹⁸²³ La propia descripción que hace Cloudflare de esos datos es el marco correcto: «Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as Browser Integrity Check» (Security Events muestra información sobre solicitudes sobre las que actuaron o que marcaron los productos de seguridad de Cloudflare, incluidas funciones como Browser Integrity Check).²⁴ La mitad local es un escáner que revisa la propia Mac por niveles cada 10 minutos: los procesos y sus firmas de código, los hooks de agente de la máquina, las herramientas que suplantan binarios del sistema en su ruta, y cosas por el estilo.¹²

Lo que la mitad en la nube hace con los datos es fácil de explicar. Levanta hallazgos por severidad (crítica, alta, media) y por categoría, y ante una crítica intenta actuar antes de avisar a nadie: cuando una sola dirección está detrás de suficientes eventos, la agrega durante siete días a una lista de bloqueo de toda la cuenta que cada zona aplica en el borde.¹²⁴ Hasta los cambios del 1 de noviembre, cada una de esas acciones producía además un correo, y también lo producían cada crítica que un límite de dos horas por sitio y categoría no suprimía, el final de cada sesión y cada hora con muchos bloqueos.¹⁸⁵ El escáner local levanta sus propios hallazgos y envía él mismo por correo sus críticas.²⁵ Las Alerts de Cloudflare vienen en dos tipos, «Monitors that you define yourself, and Platform Notifications» (monitores que defines tú mismo y notificaciones de la plataforma): consultas programadas a la SQL API y alertas de producto preconfiguradas, ambas configuradas en su panel.²⁶ El mío no es ninguna de las dos: es un script en mi Mac que lee él mismo los eventos de firewall, lo que también significa que el ruido me toca arreglarlo a mí.

3. Lo que la literatura ya decía

Nada de lo que sigue es nuevo, y esa es la parte incómoda. Había leído casi todo y aun así construí el monitor de un correo por evento.

Tres salidas, y el correo no es una de ellas. La introducción de Site Reliability Engineering (el libro de Google sobre ingeniería de confiabilidad de sitios) dice «There are three kinds of valid monitoring output» (hay tres tipos de salida de monitoreo válidos): las alertas, que «Signify that a human needs to take action immediately» (indican que una persona debe actuar de inmediato); los tickets, que «Signify that a human needs to take action, but not immediately.» (indican que una persona debe actuar, pero no de inmediato); y el registro, donde «No one needs to look at this information, but it is recorded for diagnostic or forensic purposes.» (nadie necesita mirar esta información, pero se registra con fines de diagnóstico o forenses).⁷ La misma página es tajante con el diseño que yo tenía: «a system that requires a human to read an email and decide whether or not some type of action needs to be taken in response is fundamentally flawed» (un sistema que exige que una persona lea un correo y decida si hace falta alguna acción en respuesta tiene un defecto de fondo).⁷ Ordenados así, mis 55 correos por bloqueo eran registro entregado como alertas. El borde ya había actuado; a una persona no le quedaba nada por hacer.

Toda página debe ser accionable. El capítulo de Rob Ewaschuk sobre monitoreo en el mismo libro define una alerta como «A notification intended to be read by a human and that is pushed to a system such as a bug or ticket queue, an email alias, or a pager» (una notificación pensada para que la lea una persona y que se empuja a un sistema como una cola de bugs o tickets, un alias de correo o un buscapersonas), y su nota al pie sobre las de correo dice «Sometimes known as “alert spam,” as they are rarely read or acted on.» (a veces llamadas «alert spam», porque rara vez se leen o se atienden).⁹ Las reglas del capítulo para las páginas caben en tres líneas: «Every page should be actionable.» (toda página debe ser accionable) «I can only react with a sense of urgency a few times a day before I become fatigued.» (solo puedo reaccionar con urgencia unas pocas veces al día antes de agotarme) «If a page merely merits a robotic response, it shouldn’t be a page.» (si una página solo merece una respuesta robótica, no debería ser una página).⁸ Mi respuesta robótica a un correo por bloqueo era borrarlo. El capítulo también nombra el costo del ruido: «When pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise.» (cuando las páginas llegan con demasiada frecuencia, la gente duda, lee en diagonal o incluso ignora las alertas, a veces hasta una página «real» enmascarada por el ruido).²⁷ Y describe un equipo que «spent significant amounts of time triaging the alerts to find the few that were really actionable» (dedicó mucho tiempo a clasificar las alertas para encontrar las pocas realmente accionables), lo cual describe bastante bien mi tarde del 1 de noviembre.²⁸

Síntomas antes que causas, y una prueba para una página. El ensayo anterior de Ewaschuk, que según él sentó las bases de ese capítulo, comprime la prueba en una frase: «Pages should be urgent, important, actionable, and real.» (las páginas deben ser urgentes, importantes, accionables y reales).²⁹ Sobre las causas dice «Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes» (incluye información sobre causas en páginas basadas en síntomas o en paneles, pero evita alertar directamente sobre causas), bajo una sección titulada «Cause-based alerts are bad (but sometimes necessary)» (las alertas basadas en causas son malas, aunque a veces necesarias).²⁹ Leo un bloqueo del firewall como un hecho a nivel de causa: un escáner tocó una regla. El síntoma que me importa es una ruta sensible servida o un sitio caído, y según mi lectura ninguno de los 74 informó de ninguna de las dos cosas; las solicitudes a rutas de sondeo de ese día no mostraron ningún 2xx en una ruta sensible.³ El ensayo también anticipa el resumen: «A daily (or more frequent) report can work too» (un informe diario, o más frecuente, también puede funcionar), con la advertencia de que «without a system of accountability this amounts to less-spammy email alerts» (sin un sistema de rendición de cuentas, esto equivale a alertas por correo un poco menos molestas).³⁰ Su remedio es una persona: «make sure the oncall person (or someone else) is designated to triage these every day» (asegúrate de que la persona de guardia, u otra, esté designada para clasificarlos cada día).³⁰ En un monitor de una sola persona, esa persona solo puedo ser yo. El campo de desenlace de la sección 4 es un mecanismo de apoyo mío, no suyo: le da a la clasificación diaria algo que revisar, qué fue de cada crítica, pero no hace la clasificación.

Precisión y exhaustividad. El capítulo sobre alertas de The Site Reliability Workbook (el libro de ejercicios que acompaña al de SRE) da el vocabulario para lo que salió mal. La precisión es «The proportion of events detected that were significant.» (la proporción de eventos detectados que fueron significativos). La exhaustividad es «The proportion of significant events detected.» (la proporción de eventos significativos que se detectaron).³¹ No medí la exhaustividad de mi monitor, que requiere contar los eventos significativos que se le escaparon, y la sección 5 describe uno que se le escapó. Como flujo de correo, su precisión era casi nula: 74 correos y, según mi lectura, ningún mensaje entre ellos me pedía hacer nada. El mismo capítulo nombra el tiempo de reinicio, «How long alerts fire after an issue is resolved. Long reset times can lead to confusion or to issues being ignored.» (cuánto siguen disparándose las alertas después de resolver un problema; los tiempos largos pueden causar confusión o que se ignoren los problemas).³¹ El tiempo de reinicio se define para alertas que siguen disparándose; un correo por bloqueo se dispara una vez y después no trae ninguna actualización de resolución: nunca dice que el escáner se fue.

La versión hospitalaria del mismo fallo. El propio capítulo de SRE apunta fuera del software, a la gestión de alarmas cardíacas, «for an example of alert fatigue in another context.» (como ejemplo de fatiga de alertas en otro contexto).²⁸ La Sentinel Event Alert de The Joint Commission sobre la seguridad de las alarmas de dispositivos médicos, publicada el 8 de abril de 2013, le pone números: «The number of alarm signals per patient per day can reach several hundred» (el número de señales de alarma por paciente y día puede llegar a varios cientos) e «It is estimated that between 85 and 99 percent of alarm signals do not require clinical intervention» (se estima que entre el 85 y el 99 por ciento de las señales de alarma no requieren intervención clínica).¹⁰ La alerta es cuidadosa de una forma que vale la pena copiar: el 85 a 99 por ciento abarca las alarmas que no necesitan intervención, no solo las falsas, y la alerta no separa unas de otras. La consecuencia que registra es aquella en la que yo ya iba a medio camino: el personal clínico «become desensitized or immune to the sounds» (se vuelve insensible o inmune a los sonidos) y «may turn down the volume of the alarm, turn it off, or adjust the alarm settings outside the limits that are safe and appropriate for the patient» (puede bajar el volumen de la alarma, apagarla o ajustarla fuera de los límites seguros y adecuados para el paciente).¹⁰ Cuenta 98 eventos relacionados con alarmas entre enero de 2009 y junio de 2012, de los cuales 80 «resulted in death» (terminaron en muerte), y, más allá de los factores informados a su base de datos, señala la fatiga de alarmas como «the most common contributing factor.» (el factor contribuyente más común).¹⁰ Lo que me juego yo es muchísimo menos. El mecanismo es el mismo: una persona que aprende que las alarmas no la necesitan lo aprende también para la siguiente que sea real.

NIST, antes y ahora. La revisión de 2012 de la guía de gestión de incidentes del NIST, SP 800-61r2, advertía que «it is not uncommon for an organization to receive thousands or even millions of intrusion detection sensor alerts per day.» (no es raro que una organización reciba miles o incluso millones de alertas de sensores de detección de intrusiones al día).³² La revisión de abril de 2025, SP 800-61r3, que «supersedes SP 800-61r2» (sustituye a SP 800-61r2), elimina esa frase; su línea más cercana es la recomendación de que «The volume of potentially adverse events to be analyzed is generally quite high, so organizations should rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis.» (el volumen de eventos potencialmente adversos que analizar suele ser muy alto, así que las organizaciones deberían apoyarse en soluciones técnicas que filtren grandes conjuntos de eventos hasta un subconjunto apto para que lo vean y analicen personas).³³ Tomo el filtro como la instrucción y el resumen como un filtro.

Una encuesta de proveedor, presentada como tal. La encuesta de 2023 de Vectra AI, realizada por Sapio Research entre 2.000 analistas de seguridad, informa que «SOC teams receive an average of 4,484 alerts per day, and over two-thirds (67%) of them are ignored.» (los equipos de SOC reciben un promedio de 4.484 alertas al día, y más de dos tercios, el 67 %, se ignoran).³⁴ Es una encuesta de opinión encargada por un proveedor, y el 67 por ciento es lo que dijeron los encuestados, no una medición. La cito para un solo punto: el fallo también se da a pequeña escala. Los analistas dicen que ignoran dos tercios de 4.484 alertas al día, y un lector sin equipo dejó de leer en 74.

4. El rediseño, en forma de reglas

El cambio entró a las 13:50 del 1 de noviembre, 18 minutos después de mi mensaje, y un segundo cambio a las 14:00 endureció una de sus condiciones.¹⁸ Lo escribí como reglas, cada una con el motivo de su existencia.

Regla 1: un resumen al día, y es el latido. La primera ejecución del monitor después de las 07:00, hora local, envía un correo que cubre la ventana desde el resumen anterior.¹⁸³⁵ La propia descripción del resumen dice qué reemplaza el correo: «One email a day … in place of an email per auto-block and per WAF-handled CRITICAL.» (un correo al día… en lugar de un correo por cada bloqueo automático y por cada CRITICAL resuelta por el WAF).³⁵ Empieza con la salud de las ejecuciones (ejecuciones registradas, ejecuciones iniciadas y terminadas, fallos, correos críticos enviados y suprimidos), y luego trae los bloqueos automáticos con zona, motivo y operador de red, cada crítica y lo que fue de ella, los hallazgos por severidad y categoría, las rutas sondeadas y los hallazgos sin resolver del escáner local.¹² El motivo del resumen es la bandeja de entrada. El motivo de enviarlo a diario está en la misma descripción: «The digest is also the heartbeat: it goes out on a quiet day too» (el resumen también es el latido: sale incluso en un día tranquilo).³⁵ Un flujo de alertas que solo habla cuando pasa algo no puede mostrarme la diferencia entre un día tranquilo y un monitor muerto. Un resumen que siempre llega sí puede: el silencio significa avería, no calma. Las propias notas del programa registran por qué me importa: a principios de 2026 el monitor estuvo muerto durante meses y nada lo notó.³⁵

Regla 2: los bloqueos van al chat, no al correo. Las notas de diseño lo dicen en cuatro palabras: «Per block: Slack only.» (por bloqueo: solo Slack).³ Un bloqueo es el borde actuando en mi nombre. En los términos del libro de SRE es registro: queda anotado, sirve más adelante y no requiere que una persona actúe.⁷ El chat conserva el flujo en vivo para los momentos en que quiero mirarlo, y el resumen conserva el registro.

Regla 3: incorporar una crítica al resumen cuando el borde ya se encargó de ella. Una crítica sigue intentando bloquear primero; después, el monitor decide si merece un correo.³ Dos condiciones la incorporan al resumen en su lugar, revisadas en este orden. La primera: la propia dirección del hallazgo, y cada dirección del hallazgo apta para bloqueo automático, ya está en la lista de bloqueo activa, así que el borde ya está deteniendo esas direcciones.³¹⁴ Esa verificación no mira ninguna otra dirección y se ejecuta antes de examinar la muestra, así que una avalancha incorporada por ella aún puede contener eventos sin bloqueo ni desafío registrado, de direcciones por debajo del umbral de bloqueo; esta rama dice que los objetivos del respondedor están bloqueados, no que cada evento se haya mitigado. La segunda se aplica a una avalancha de WAF, una ráfaga de eventos de firewall en una zona: solo la incorpora cuando cada evento de la muestra, sea de bot o no, tiene un bloqueo o un desafío registrado, y la muestra está completa. «A solved or bypassed challenge, log, allow and skip all count as unmitigated.» (un desafío resuelto o eludido, log, allow y skip cuentan todos como no mitigados).³ Las definiciones de Cloudflare explican por qué esos cuatro cuentan en contra de la incorporación: después de un desafío, «If successful, Cloudflare accepts the matched request» (si se supera, Cloudflare acepta la solicitud que coincidió), y una acción log solo «Records matching requests in the Cloudflare Logs.» (registra las solicitudes coincidentes en los Cloudflare Logs).³⁶ Un hallazgo de escáner persistente, que solo cuenta eventos que el borde bloqueó o desafió, se incorpora por la regla del WAF por ese motivo, o por la regla de la lista de bloqueo cuando su dirección ya está en la lista, como ocurrió con el del 2 de noviembre.³ Todo lo demás se envía por correo de inmediato.

Regla 4: el desenlace va en el hallazgo. La política es que cada crítica de la mitad en la nube lleve un desenlace registrado: incorporada porque la dirección está en la lista de bloqueo, incorporada porque el borde bloqueó o desafió cada evento muestreado, enviada por correo, suprimida (dentro del límite de un correo por sitio y categoría cada dos horas) o con fallo de correo.³³⁷ El registro no está a la altura de la política. De las críticas fechadas el 1 de noviembre en UTC, 118 no llevan desenlace: 117 se levantaron antes de que el campo existiera, y una crítica de la nube, a las 14:13 PST, llegó después; su ejecución fue una de las tres de la sección 7 que terminaron unos cuatro minutos después de empezar, y se detuvo durante el bloqueo automático, antes de que se escribiera un desenlace. Las críticas del escáner local nunca llevan uno; las tres del 2 de noviembre no tienen ninguno.³⁷³⁸ Desde el 3 de noviembre, el monitor escribe «pending» (pendiente) en una crítica antes de que se ejecute el bloqueo automático, así que una ejecución cortada a la mitad deja un estado visible en lugar de un vacío.¹⁴ El resumen imprime el desenlace junto a cada crítica de la nube, bajo un encabezado que lo promete: «Every CRITICAL and what became of it» (cada CRITICAL y qué fue de ella).¹² El campo de desenlace es mi mecanismo, no el de Ewaschuk. Su condición para un informe diario es una persona designada para clasificarlo cada día, y aquí esa persona soy yo; el campo le da a esa clasificación algo que revisar.³⁰ Con el desenlace en cada línea, el resumen responde la pregunta que hice el 1 de noviembre, rutina o algo real, crítica por crítica, aunque «enviada por correo» o «incorporada» dice adónde fue una crítica, no que algo se haya resuelto.

Regla 5: la alerta horaria de volumen se queda. Otra vez las notas: «Hourly volume alert (responder): still immediate, at most once an hour» (alerta horaria de volumen del respondedor: sigue siendo inmediata, como mucho una vez por hora).³ Un bloqueo aislado es rutina; un montón repentino de bloqueos en una hora es lo más parecido a un síntoma que tiene la mitad en la nube, un cambio en lo que internet me está haciendo. Se disparó una vez el 2 de noviembre.⁵

Regla 6: las críticas del escáner local siguen enviando correo de inmediato. Las notas de diseño las mantienen inmediatas porque se supone que son raras.³ Yo las mantengo por un segundo motivo: nada se interpone entre mi Mac y un hallazgo local como el borde se interpone entre mis sitios y un escáner. Una lista de bloqueo puede detener una dirección; nada fuera de la Mac detiene un proceso dentro de ella. El costo de esa regla aparece en la sección 7.

El día en que las reglas entraron en vigor, recortaron el flujo de correo de 74 correos antes de las 13:32 a siete registrados en el resto del día (seis críticos y una alerta horaria), más el resumen que envié a mano.⁵² El pronóstico que escribí aquella tarde decía «Under today’s traffic that would have been 0 immediate emails instead of 16.» (con el tráfico de hoy, habrían sido 0 correos inmediatos en lugar de 16).¹ No se cumplió, y la sección 6 explica por qué.

5. El caso de prueba: 2 de noviembre, de 11:03 a 11:21

La primera prueba real de las reglas llegó a la mañana siguiente: una dirección de un proveedor de hosting neerlandés pasó un escáner de vulnerabilidades por mi sitio.¹² Esto es lo que escribió el monitor, textual de su log en hora local del Pacífico, con la dirección reemplazada por «[the address]» y las líneas intermedias omitidas.⁴

[2026-11-02 11:03:53] [INFO] New finding [critical]: Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:02] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:04:03] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:04] [INFO] New finding [critical]: Scanner from [the address] on blakecrosley.com
[2026-11-02 11:04:05] [RESPOND] [INFO] Skip: [the address] already has active real block in blakecrosley.com (dedup)
[2026-11-02 11:04:05] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Scanner from [the address] on blakecrosley.com
[2026-11-02 11:09:22] [INFO] New finding [critical]: 726 WAF blocks in 5 minutes
[2026-11-02 11:09:23] [INFO] Critical alert folded into the daily digest (IP on the block ledger): 726 WAF blocks in 5 minutes
[2026-11-02 11:09:44] [INFO] New finding [critical]: Persistent scanner: [the address] blocked 743 times today
[2026-11-02 11:09:47] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:09:47] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Persistent scanner: [the address] blocked 743 times today

Minuto a minuto:

• 11:03:53. El detector de avalanchas de solicitudes levanta una crítica contra la dirección. Ocho segundos después, a las 11:04:01, el respondedor la agrega a la lista de bloqueo, y a las 11:04:02 el aviso de bloqueo va al chat con su correo incorporado al resumen.⁴
• 11:04:03. La crítica misma se incorpora: la dirección ya está en el registro de bloqueos, así que el borde ya está haciendo el trabajo que un correo me pediría hacer.⁴
• 11:04:04. Un segundo detector, la verificación de escáneres, levanta su propia crítica para la misma dirección. La solicitud de bloqueo del respondedor se omite por duplicada, y la crítica se incorpora un segundo después.⁴
• 11:09:22. El detector de avalanchas de WAF levanta una tercera crítica para la zona. Su infractor está en el registro, y se incorpora.⁴¹¹ Solo decide la incorporación por lista de bloqueo: ocho de los eventos muestreados no tenían bloqueo ni desafío registrado y la muestra estaba topada, así que la incorporación por WAF por sí sola la habría enviado por correo.¹¹
• 11:09:44. La verificación de escáner persistente, que cuenta los eventos que el borde bloqueó o desafió de una sola dirección en todas mis zonas, levanta la cuarta, registrada en otro de mis sitios: 743 eventos bloqueados o desafiados de esa dirección ese día.¹² El respondedor escribe la dirección en la lista por segunda vez (un defecto, más abajo), publica en el chat e incorpora la crítica a las 11:09:47.⁴¹¹
• 11:14:58 y 11:20:40. Dos críticas más de avalancha de WAF para la misma zona; ambas se incorporan de la misma manera.¹¹

Cuatro críticas en 5 minutos y 51 segundos, seis hasta las 11:20, todas registradas en sus hallazgos como incorporadas porque la dirección estaba bloqueada.¹¹ Una dirección bloqueada, con su entrada en la lista escrita dos veces porque la verificación de duplicados funcionaba entonces por sitio (corregido el 3 de noviembre), y otras cuatro solicitudes de bloqueo omitidas por duplicadas.⁴¹⁴ Correos: cero. El log no registra ningún correo enviado entre las 11:03 y las 11:21; la única crítica de esa ventana que ni se incorporó ni se envió por correo, suprimida a las 11:03:13, era una avalancha en otro sitio desde otra dirección.⁴

El siguiente resumen lo llevó como dos filas en la tabla de bloqueos automáticos (el primer bloqueo, con su zona, motivo y operador de red, y la nueva inserción del escáner persistente) y seis filas en la tabla de todas las críticas, cada una marcada «blocked» (bloqueada) o «blocked earlier» (bloqueada antes).¹² Según mi lectura, ese es el peso justo para un escáner que el monitor bloqueó ocho segundos después de su primer hallazgo, ocho minutos después de que empezara el escaneo: unas pocas líneas que puedo leer con el café, no una página.⁴

Hay algo que el caso de prueba no muestra, encontrado el 3 de noviembre. El mismo escáner también estaba enviando mensajes al formulario de contacto de mi sitio, mensajes a los que mi aplicación respondió con un 200, como mucho 31 correos propios, el tema del post que lo acompaña, y la verificación de avalanchas de formularios del monitor no levantó ningún hallazgo en vivo; al reproducirla sobre datos completos para los cinco minutos hasta las 11:03:23, la misma verificación levanta el hallazgo, con severidad alta (una línea del resumen, no un correo ni un bloqueo), a partir de 39 envíos, 23 de ellos rechazados.³⁹ La ejecución en vivo le había pedido a Cloudflare una ventana que terminaba en el instante de la consulta, 37 segundos después de iniciar la ejecución, antes de que los eventos más recientes hubieran llegado por completo: contó 1.914 solicitudes de la dirección en esa ventana, donde la reproducción sobre datos completos cuenta 2.143.⁴³⁹ Ese retraso está medido sobre todas las solicitudes de la dirección, no sobre los envíos al formulario que cuenta la verificación; según mi lectura, el mismo retraso mantuvo esos envíos por debajo del umbral de la verificación en vivo. Además, cada ejecución miraba exactamente cinco minutos hacia atrás mientras las ejecuciones arrancaban con unos 5,6 a 5,8 minutos de separación, así que una parte de cada intervalo nunca se escaneaba.³⁹¹⁷ La corrección entró ese mismo día: cada ventana empieza ahora donde terminó la anterior y termina 90 segundos antes de la ejecución, salvo que el registro anterior falte, tenga menos de un minuto o más de 15 minutos de antigüedad, como después de que la Mac duerma, en cuyo caso la ejecución vuelve a una simple mirada de cinco minutos hacia atrás.³⁹ Reproducir la ventana del 2 de noviembre con el código modificado da los mismos hallazgos, así que el cambio no alteró la detección en una ventana fija. Una reproducción no puede poner a prueba el encadenamiento de ventanas ni el retraso, que solo actúan en ejecuciones en vivo; las ejecuciones en vivo a partir del 3 de noviembre son su prueba.³⁹

6. Qué sigue enviando correo, y por qué

El 2 de noviembre fue el primer día completo con las reglas nuevas, y envió 19 correos, no uno: 14 críticos, una alerta horaria de volumen, un resumen y tres del escáner local.⁵ No salió ningún correo por bloqueo; en su lugar, 108 avisos de bloqueo se incorporaron al resumen, 177 críticas se incorporaron y otras 37 quedaron suprimidas por el límite de dos horas, todo contado por día local; los conteos de desenlaces más adelante en este post van por fecha UTC, y por eso esas cifras difieren.⁵

Correos por día local y por flujo; el 31 de octubre solo cubre los 89 minutos posteriores al inicio del log.⁵

Cada crítica de la nube que se envió por correo desde el cambio de las 13:50 hasta el final del 2 de noviembre, 20 en total (seis en el resto del 1 de noviembre, catorce el 2 de noviembre), fue una avalancha de WAF en resumegeni.com o blakecrosley.com en la que al menos un evento no tenía bloqueo ni desafío registrado.¹³ La incorporación por WAF rechazó cada una correctamente según su propia regla: había un evento sin mitigar en la muestra, así que el monitor no podía afirmar que el borde se hubiera encargado.³ En esas avalanchas ninguna dirección tenía suficientes eventos para ser apta para bloqueo automático, así que la incorporación por lista de bloqueo no tenía ninguna dirección que revisar.¹³ El resumen nombra al grupo de la misma manera: «a CRITICAL that was neither blocked nor already handled by the WAF» (una CRITICAL que ni se bloqueó ni había resuelto ya el WAF).¹²

Los asuntos de esos correos contaban otra historia, y eso era un defecto. El resumen de la avalancha decía «N WAF blocks in 5 minutes» (N bloqueos de WAF en 5 minutos), pero N contaba cada evento de firewall que no venía de bots en la ventana, fuera cual fuera la acción que tomó el borde.¹³ Dos ejemplos de los hallazgos, en hora local:

El primer correo afirmaba 104 bloqueos cuando el borde no había bloqueado nada.¹³ Según mi lectura, un asunto que dice «bloqueos» sobre eventos sin ningún bloqueo registrado es peor que el ruido: le dice al único lector que el sistema se encargó de algo de lo que quizá no se encargó. Mi primera corrección, el 3 de noviembre, el día en que se hicieron estos conteos, también estaba mal. Mantenía el conteo sin bots para N y contaba bloqueados, desafiados y el resto sobre todos los eventos, así que la ráfaga de las 16:51 habría dicho 104 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 through, dos poblaciones en una línea. La revisión de este post lo detectó, y lo volví a corregir ese mismo día.¹⁴ El resumen de la avalancha, y con él el asunto del correo, cuenta ahora una sola población, cada evento de firewall muestreado, y dice N WAF events in 5 minutes: B blocked, C challenged, U unmitigated (S from non-bot user agents); un desafío de JavaScript cuenta como desafiado, y el motivo del bloqueo automático dice N WAF events from this address in 5 min.¹⁴ Para la ráfaga de las 16:51 eso da 117 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 unmitigated (104 from non-bot user agents).¹³¹⁴ La incorporación por WAF ya se basaba en los eventos sin mitigar, así que el asunto y la decisión cuentan ahora lo mismo. La corrección cambia lo que dicen los 14 asuntos. No cambia cuántos se enviaron, y 19 sigue siendo el número honesto del 2 de noviembre.

El pronóstico que escribí el 1 de noviembre falló porque su premisa estaba equivocada. Decía que las reglas nuevas «would have been 0 immediate emails instead of 16» (habrían sido 0 correos inmediatos en lugar de 16), partiendo de la creencia de que, en las siete críticas posteriores a las 00:30 de esa mañana, «Cloudflare had already blocked every one of those requests.» (Cloudflare ya había bloqueado cada una de esas solicitudes).¹ Los hallazgos dicen otra cosa también sobre esas: las cinco que el log muestra enviadas por correo después de las 00:30 registran como mucho un bloqueo y nueve desafíos cada una, frente a 76 a 89 eventos en sus resúmenes.¹³ Y en cada una de las seis críticas que se enviaron por correo aquella tarde y noche, el borde había bloqueado o desafiado solo una parte de los eventos (ninguno en la ráfaga de las 16:51), así que incluso la regla de las 13:50, que solo incorporaba cuando los bloqueos y desafíos cubrían cada evento sin bots, habría enviado todas por correo.¹³¹ Diez minutos después del cambio de las 13:50, un segundo cambio hizo que la incorporación por WAF contara cada evento, viniera o no de un user agent de bot, y que solo confiara en una muestra completa; endureció la regla, pero no es la razón por la que falló el pronóstico.¹⁸³ El pronóstico contaba los bloqueos en los que yo creía; la regla contaba los eventos que estaban ahí.

Lo que no sé es si esos 14, las críticas del 2 de noviembre que se enviaron por correo, merecían un correo. Los hallazgos registran cuántos eventos quedaron sin mitigar, es decir, sin bloqueo ni desafío registrado, pero no qué acciones llevaban: una regla log, un skip, un allow o un desafío que un cliente resolvió.¹³ Un evento sin mitigar tampoco es una solicitud que llegó a mi sitio. Cloudflare dice «A single HTTP request can generate one or more security events when it triggers security features» (una sola solicitud HTTP puede generar uno o más eventos de seguridad cuando activa funciones de seguridad), y enumera log y skip como acciones que no terminan la evaluación de reglas como lo hace un bloqueo, así que, según mi lectura, otra regla aún puede actuar sobre la misma solicitud.²⁴³⁶ El tutorial de GraphQL de Cloudflare muestra el campo action y valores de ejemplo como "log" y "block", pero no enumera todos los valores que el campo puede tomar.²³ El panel de Security Events de Cloudflare también muestrea: «For large volumes of traffic, Cloudflare uses sampling to return results faster.» (para grandes volúmenes de tráfico, Cloudflare usa muestreo para devolver resultados más rápido).²⁴ Hasta que el monitor registre las acciones detrás de cada evento sin mitigar y vincule los eventos con las solicitudes, no puedo decir cuáles de esos correos describían tráfico que el borde dejó pasar, y la respuesta decide si merecen un correo.

Los tres correos locales del 2 de noviembre son el otro tema abierto. Informan una «Browser -> shell chain» (cadena de navegador a shell) a las 13:50 en la que una shell lanzó curl, y siguen sin resolver en los hallazgos.⁴⁰ No he verificado si eran las herramientas de agente que estaba usando aquella tarde o algo más, así que no los cuento como falsas alarmas.

7. Dos señales falsas

El minero de criptomonedas que era Spotlight

A las 10:03 del 1 de noviembre, el escáner local levantó una crítica, «High CPU unsigned process - possible crypto miner» (proceso sin firmar con CPU alta, posible minero de criptomonedas), contra spotlightknowledged, el propio daemon de Spotlight de Apple, al 74,9 por ciento de CPU, y dos segundos después registró «Critical email sent».¹⁵ El bug era mío. La verificación buscaba la frase «valid on disk» en la salida del comando que muestra la firma de código, codesign -d. Las notas del escáner registran ahora el fallo en una cláusula: la frase es una «which only codesign -v prints, so every process read as unsigned» (que solo imprime codesign -v, así que cada proceso se leía como sin firmar).²⁵ Una lista de exclusiones había ocultado el fallo hasta que un daemon de un framework de Apple tuvo un pico, y mi log de ese día lo dice.¹ El hallazgo lleva ahora su resolución: «false positive, Apple platform binary» (falso positivo, binario de la plataforma de Apple).⁴¹

Costó un correo, el único correo local del 1 de noviembre.⁵ Las 16 críticas locales anteriores, del 31 de octubre y el 1 de noviembre, marcaron Xcode, el Python de Homebrew, mis propias compilaciones de apps, cambios en hooks, shims de gestores de versiones en la ruta, un patrón de gusano de IA que coincidía con las instrucciones de agente de otro proyecto y una verificación de event taps que coincidía con su propia consulta; produjeron 15 intentos de envío, y todos fallaron.^5251915 El servicio de correo está detrás de Cloudflare, que respondió al user agent predeterminado de Python con el error 1010 antes de leer la clave; lo reproduje con una clave deliberadamente mala.¹⁹ La página de Cloudflare sobre el error nombra a ese cliente directamente, en su nota sobre hosts de Pages y Workers: «a User-Agent header that Browser Integrity Check treats as a non-browser client (for example, the default Python urllib user agent).» (un encabezado User-Agent que Browser Integrity Check trata como un cliente que no es navegador, por ejemplo el user agent predeterminado de urllib de Python).⁴² Un remitente roto me ahorró 15 correos sobre mis propias herramientas y mis propios cambios.¹⁵ Las notas del escáner dicen la lección más amplia sin rodeos: «most of the CRITICALs it raised in its first live days were its own noise.» (la mayoría de las CRITICAL que levantó en sus primeros días en vivo eran su propio ruido).²⁵ Aun así mantengo inmediatas las críticas locales, y corrijo cada falsa en su verificación en lugar de silenciar el flujo.

RUNS SHORT 162/207

El primer resumen programado, en la mañana del 2 de noviembre, llevaba el asunto «Mon Nov 2: 71 blocks on 15 zones, 11 criticals emailed, RUNS SHORT 162/207» (lunes 2 de nov.: 71 bloqueos en 15 zonas, 11 críticas enviadas por correo, faltan ejecuciones 162/207).¹⁶ La regla del resumen era aritmética simple: el número esperado de ejecuciones son los minutos de la ventana divididos entre cinco, y el asunto señala el déficit.³⁵ La ventana fue de las 13:48 del 1 de noviembre a las 07:05 del 2 de noviembre, 1036,5 minutos, o sea 207 franjas de cinco minutos; el log registró 162 ejecuciones.¹⁷

Mi log del 2 de noviembre explicó el hueco en una línea: «The RUNS SHORT line is the Mac asleep» (la línea RUNS SHORT es la Mac dormida), sin falla en el monitor.⁴³ Esa línea acierta en que el monitor no falló (ninguna ejecución del 2 de noviembre quedó sin terminar) y se equivoca sobre la causa, tanto el 2 de noviembre como en la ventana que describía el número. El análisis de huecos entre ejecuciones reparte las 45 franjas faltantes, de forma aproximada, en unas 25 perdidas por la cadencia, unas 16 por el sueño, más o menos una más en un hueco largo después de una ejecución que terminó antes de tiempo, y tres ejecuciones que nunca se registraron.¹⁷

El registro de energía muestra reposo por inactividad a las 23:21:30 y despertar completo a las 00:30:05, y de nuevo reposo por inactividad a las 06:01:20 y despertar completo a las 06:30:28.⁴⁴ Las tres ejecuciones empezaron a las 14:09, 14:19 y 23:10 del 1 de noviembre; cada una terminó unos cuatro minutos después sin línea de cierre registrada, lo que según mi lectura es el watchdog (el proceso vigilante que mata ejecuciones colgadas) de 240 segundos. Una cuarta ejecución terminó 28 segundos después de empezar sin causa visible.¹⁷³⁸ En el día calendario del 2 de noviembre empezaron 242 ejecuciones frente a 288 franjas de cinco minutos, 46 de menos, y ninguna quedó sin terminar; solo dos huecos pasaron de 10 minutos, 35,8 minutos en total, así que también ese día la mayor parte del déficit fue la cadencia, no el sueño.¹⁷

La suposición equivocada era mía, en el resumen: un programador configurado a cinco minutos entregaba una ejecución cada 5,6 a 5,8 minutos más o menos, incluso con la Mac despierta, así que la aritmética de cinco minutos llamaría corto a un día sano.¹⁷ No he determinado por qué la cadencia en vigilia va lenta. Reemplacé la aritmética el 3 de noviembre. La salud de las ejecuciones informa ahora las ejecuciones registradas, la mediana de minutos entre ellas y el hueco más largo con su hora, y el asunto solo señala un hueco de más de 20 minutos. La vista previa de esa mañana decía «about one every 5.6 min» (aproximadamente una cada 5,6 min), y su asunto terminaba en «RUN GAP 31 min at 05:56» (hueco de 31 min a las 05:56).¹⁴ Un hueco es un síntoma sobre el que puedo actuar: la Mac se durmió o el monitor se detuvo. Una proporción frente a una cadencia que el programador nunca entregó no era ninguna de las dos cosas.

Las reglas que me quedé

1. Cuenta el correo antes de cambiarlo, por flujo y con una regla explícita. Mi tabla y el conteo del log coincidieron en 74 solo porque primero anoté qué contaba como correo.¹²
2. Registra «sent» solo cuando el servicio de correo dice que sí. De 22 de mis 74 correos puedo probar un intento y nada más.²⁶
3. Un bloqueo que el borde ya hizo es una línea de log, no una alerta. Las tres salidas del libro de SRE lo ponen ahí, y pasar 55 correos por bloqueo al chat no me hizo perder nada sobre lo que hubiera actuado.⁷⁵
4. Envía un resumen diario aunque no haya pasado nada. Un resumen que siempre llega es el latido; su ausencia es la alerta.³⁵
5. Incorpora una crítica al resumen solo con una condición que el borde demuestre. Las mías son que las direcciones bloqueables del hallazgo ya estén en la lista de bloqueo y una muestra completa en la que cada evento tenga un bloqueo o un desafío registrado, y la segunda es la razón por la que 14 aún se enviaron por correo el 2 de noviembre.³¹³
6. Escribe el desenlace en cada crítica de la nube. Un informe diario del que nadie responde es, en palabras de Ewaschuk, «less-spammy email alerts» (alertas por correo un poco menos molestas); el desenlace en cada línea es lo que revisa mi clasificación diaria.³⁰¹²
7. Haz que el asunto diga lo que hizo el borde. «104 WAF blocks» en una ráfaga con cero bloqueos fue mi peor línea de la semana.¹³
8. Informa huecos, no proporciones frente a un horario. Un temporizador de cinco minutos entregaba una ejecución cada 5,6 minutos más o menos, así que 162/207 parecía una caída y era sobre todo un reloj.¹⁷
9. Corrige una falsa alarma en su verificación, no en la bandeja de entrada. Una salida de comando mal leída convirtió el daemon de Spotlight de Apple en un minero de criptomonedas; la corrección fue a la verificación.²⁵

Qué podría cambiar

• Si los eventos sin mitigar resultan ser desafíos resueltos, eso por sí solo no convertiría en ruido las críticas de avalancha de WAF que aún se envían por correo. Cuando un cliente supera un desafío, «Cloudflare accepts the matched request» (Cloudflare acepta la solicitud que coincidió): la solicitud sigue adelante, y eso no demuestra que fuera inofensiva ni que nada requiera respuesta. Incorporar esas críticas exigiría evidencia de solicitudes vinculada a los mismos eventos que mostrara que nada en ellos necesitaba a una persona, y completar un desafío no es, por sí solo, esa evidencia. Si resultan ser reglas log o skip, la pregunta es si esas reglas hacen lo que yo pretendía, y cada correo vale la pena leerlo hasta que lo sepa. El monitor todavía no registra cuál de los dos casos es.¹³³⁶
• Si los correos críticos de un día vuelven a acercarse a las decenas, el límite de dos horas por sitio y categoría está haciendo el trabajo que debería hacer una regla, y la regla necesita otra revisión.³
• Si el resumen deja de llegar, algo entre el monitor y mi bandeja de entrada se detuvo: el monitor, la Mac en la que corre, el remitente o la ruta de entrega, ya que un envío aceptado todavía no es uno entregado. Ese es el único silencio que el diseño trata como señal para ir a mirar.³⁵²⁰
• Si el escáner local levanta una crítica que no puedo explicar con mis propias herramientas, el correo inmediato fue la decisión correcta; los tres hallazgos de cadena de shell sin resolver del 2 de noviembre son la prueba abierta de eso.⁴⁰
• Si agrego un lector, las páginas y los tickets dejan de ir a la misma persona, y la separación del libro de SRE entre alertas y tickets necesitaría una cola de tickets, no mi bandeja de entrada.⁷

Conclusiones clave

Si operas un monitor para ti mismo

• Dejé de leer en algún punto antes de los 74 correos en medio día, una cifra que mi bandeja de entrada alcanzó a primera hora de la tarde.¹
• Un resumen diario que también llega en días tranquilos es un latido gratis; un monitor que solo habla cuando hay eventos no puede avisarte de que murió.³⁵
• Tus logs pueden decir «sent» de correo que nunca salió. Revisa el código antes de fiarte del conteo.⁶¹⁹

Si construyes uno

• Actúa primero y después decide si avisar: bloquea, y luego incorpora la alerta al resumen si la lista de bloqueo o el borde ya la cubren.³
• Registra el desenlace de cada crítica en el hallazgo e imprímelo en el resumen, para que la persona que, según Ewaschuk, debe clasificar un informe diario tenga algo que revisar; en mi monitor esa persona soy yo.³⁰¹²
• Nombra los eventos por lo que el borde registró para ellos (bloqueados, desafiados, sin mitigar), cuenta una sola población por línea y nunca los nombres por lo que esperabas que hiciera el borde.¹³¹⁴
• Mide el programador que tienes. El mío ejecutaba cada 5,6 minutos con un temporizador de cinco.¹⁷

Si eres quien lee la bandeja de entrada

• Pregunta de cada alerta si es «urgent, important, actionable, and real» (urgente, importante, accionable y real); lo que no pase la prueba va a un resumen o a un log.²⁹
• Mi pronóstico del primer día falló: decía cero críticas inmediatas, y el día siguiente envió 14.¹⁵

Preguntas frecuentes

¿Qué es la fatiga de alertas?

La fatiga de alertas es lo que les pasa a las personas que reciben demasiadas alarmas que no necesitan nada de ellas: se vuelven, en palabras de The Joint Commission, «desensitized or immune to the sounds» (insensibles o inmunes a los sonidos), y empiezan a bajar el volumen de las alarmas o a apagarlas.¹⁰ El libro de SRE de Google describe lo mismo en operaciones, donde la gente «second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise.» (duda, lee en diagonal o incluso ignora las alertas, a veces hasta una página «real» enmascarada por el ruido).²⁷ Mi propio caso tardó un día: 74 correos a las 13:32, ninguno de los cuales, según mi lectura de aquella tarde, me pedía actuar.¹

¿Cuántas alertas de seguridad al día son demasiadas?

Para una persona, la respuesta honesta del capítulo de SRE es unas pocas: «I can only react with a sense of urgency a few times a day before I become fatigued.» (solo puedo reaccionar con urgencia unas pocas veces al día antes de agotarme).⁸ La encuesta de proveedor de Vectra informa que los equipos reciben un promedio de 4.484 alertas al día y que, según su propio relato, ignoran el 67 por ciento.³⁴ Para mi monitor de una sola persona, la respuesta práctica es un resumen al día más las alertas que necesitan a una persona ahora; el 2 de noviembre eso todavía fueron 19, y trato las 14 críticas de avalancha de WAF entre ellas como una pregunta abierta y no como un costo asumido.⁵¹³

¿Las alertas de seguridad deben ir en un resumen diario o en tiempo real?

Las dos cosas, repartidas según lo que tenga que hacer la persona. Todo lo que el monitor considera ya resuelto (una dirección que puso en la lista de bloqueo, o una avalancha en la que cada evento muestreado se bloqueó o desafió) va al resumen; el resto sale de inmediato, dentro del límite de dos horas.³ Ewaschuk admite que un informe diario «can work too» (también puede funcionar), con una condición: sin rendición de cuentas «amounts to less-spammy email alerts» (equivale a alertas por correo un poco menos molestas), y quiere a alguien «designated to triage these every day» (designado para clasificarlos cada día).³⁰ En mi monitor ese soy yo, y mi resumen imprime qué fue de cada crítica de la nube para que la clasificación tenga algo que revisar.¹²

¿Qué es una alerta de latido (heartbeat)?

Un latido es un mensaje que llega según un horario, pase algo o no, de modo que su ausencia significa que algo se rompió. Mi resumen diario es el latido: «it goes out on a quiet day too» (sale incluso en un día tranquilo), así que un monitor que dejó de ejecutarse aparece como un correo que falta.³⁵ Lo mismo ocurre con un envío fallido o una entrega perdida, así que un resumen que falta es una señal para revisar el monitor, el equipo en el que corre, el remitente y la ruta de entrega.²⁰ Su sección de salud de las ejecuciones también informa el hueco más largo entre ejecuciones y señala en el asunto cualquier hueco de más de 20 minutos.¹⁴

¿Por qué las alertas del WAF de Cloudflare inundan mi correo?

Las mías inundaban porque cada bloqueo y cada crítica se convertían en su propio mensaje, y internet escanea cada zona pública todo el día.⁵ Las Alerts de Cloudflare, «Monitors that you define yourself, and Platform Notifications» (monitores que defines tú mismo y notificaciones de la plataforma), pueden entregarse por correo y se configuran en su panel; un monitor que construyes tú mismo sobre su API, como el mío, no es ninguna de las dos cosas, y hereda cualquier envío de correo por evento que le hayas programado.²⁶ Revisa también qué cuenta una alerta: entre las acciones de Cloudflare están log y skip, que no terminan la evaluación de reglas como lo hace un bloqueo, y un desafío que un cliente resuelve termina con Cloudflare aceptando la solicitud, así que «eventos de WAF» y «bloqueos de WAF» son números distintos.³⁶ Mis asuntos confundían los dos hasta el 3 de noviembre.¹³¹⁴

¿Un 2xx de la API de correo significa que la alerta se entregó?

No. El evento email.sent de Resend «Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server» (ocurre cuando la solicitud a la API tuvo éxito; Resend intentará entregar el mensaje al servidor de correo del destinatario), y la entrega es un evento aparte.²⁰ Un 2xx significa que el servicio aceptó el mensaje. Registra el código de estado y trata la entrega como una pregunta distinta.⁶

Relacionado en este sitio: Por qué el spam venció a mi formulario de contacto con límite de tasa sigue al mismo escáner del 2 de noviembre desde el lado del formulario de contacto; Lo que ejecuto antes de dormir es la verificación nocturna de producción, la otra rutina que corre mientras no miro; Lo que realmente falla cuando ejecutas agentes de IA sin supervisión nombra los modos de fallo de las sesiones de agentes desatendidas, cada uno con una señal de detección; Cada hook es una cicatriz rastrea cada uno de mis hooks de agente hasta el fallo que lo produjo, el mismo hábito que corregir una falsa alarma en su verificación; El modo auto de Claude Code no es una frontera de seguridad sostiene que el muro alrededor de un agente importa más que su clasificador; y Observabilidad de agentes de IA defiende la necesidad de ver lo que los agentes hacen con el disco, la CPU y la red.

Fuentes

Todas las horas de los datos propios del autor son hora local del Pacífico salvo que se indique UTC; el 1 de noviembre se pasó de PDT a PST a las 02:00. Las páginas públicas se consultaron el 3 de noviembre de 2026, a las horas UTC indicadas.