Hay errores que explotan y te avisan. Y hay otros, peores, que no dicen nada: todo se ve bien, los tableros en verde, y sin embargo algo no está pasando. Esta semana el nuestro fue de los segundos —todo el correo saliente estaba muerto y nadie había recibido una sola alerta.
La causa, cuando la encontramos, daba pena de lo pequeña: una letra cambiada en el usuario del servidor de correo (decía braiz donde debía decir brainz). Y al lado, otra: la dirección de remitente venía mal escrita —barinzlab.ia en vez de brainzlab.ai. Dos transposiciones de teclado, invisibles a simple vista, bastaron para que el proveedor de correo rechazara en silencio cada envío. Sumamos un tercer arreglo de higiene: la contraseña SMTP vivía en texto plano en un archivo de configuración compartido; la movimos a un secreto, donde siempre debió estar.
Los bugs que dan miedo no son los que explotan. Son los que se quedan callados: el correo no salía, el sistema marcaba verde, y la única forma de notarlo era preguntarse por qué nadie respondía.
El recibo completo de un subsistema entero caído son tres commits diminutos —dos correcciones de una letra y un secreto bien guardado. Y esa es justo la lección: el tamaño del arreglo no dice nada del tamaño del daño. Una errata en un campo de configuración no rompe el build, no lanza una excepción, no enciende una alarma —solo hace que el mundo deje de recibir tus correos mientras tú crees que todo marcha.
Lo contamos sin maquillar porque el build-in-public honesto incluye el día en que te das cuenta de que llevabas un rato gritando al vacío por una i de más. La moraleja no es 'revisa tus typos’ —es que lo que no falla ruidosamente necesita que lo vigiles a propósito. Receipts > adjectives: el recibo de hoy es una letra, y lo que costó.