Los dos tipos de fallo: el que te avisa y el que te deja creer que todo va bien
Cuando alguien pregunta cómo saber si una automatización ha fallado, casi siempre está pensando en el fallo ruidoso: el flujo se para, la herramienta manda un correo, alguien lo arregla. Ese es el fallo bueno. Es visible, es acotado y su coste es proporcional al tiempo que tarda alguien en mirar el móvil.
El problema es el otro. El fallo silencioso no se para: termina. Marca la ejecución en verde, no rompe nada y sigue corriendo mañana igual de mal. Y no salta ninguna alarma porque, técnicamente, no hay nada que alertar: cada paso hizo lo que le tocaba y devolvió sin error. La herramienta te está diciendo la verdad —«todos los pasos se ejecutaron»— y tú estás leyendo otra cosa —«el trabajo se hizo»—. No es lo mismo.
La diferencia importa porque el coste no se parece. El fallo ruidoso cuesta horas. El silencioso cuesta semanas, y cuando se descubre ya hay que reconstruir hacia atrás: qué pedidos no entraron, qué clientes no recibieron respuesta, qué facturas no se registraron. Esta guía cuelga de la de mantenimiento de las automatizaciones con IA, que explica por qué se rompen. Aquí vamos a lo otro: cómo te enteras.
Las cuatro caras del fallo silencioso
En producción se repiten cuatro, y ninguna dispara un error. Reconocerlas es la mitad del trabajo.
1. El éxito vacío
La llamada devuelve un 200 y el cuerpo viene vacío, o con una lista de cero elementos. Para el flujo eso es un éxito perfecto: pidió datos, recibió respuesta, siguió adelante. El bucle que venía después no dio ni una vuelta, así que no creó nada, así que no falló. Es el patrón número uno y el más difícil de ver, porque en el panel se ve idéntico a un día bueno.
2. El filtro que se lo come todo
Alguien cambió un nombre de campo en el CRM, o el formato de una fecha, y la condición que dejaba pasar los registros ya no la cumple ninguno. El flujo se ejecuta, filtra, y del filtro no sale nada. Ejecución correcta, cero trabajo hecho. Se distingue del anterior en un detalle: aquí sí entraron datos, simplemente ninguno superó la puerta.
3. La respuesta inservible que nadie valida
Es el fallo propio de automatizar con IA. Le pides al modelo que devuelva una categoría o un JSON, y devuelve una disculpa, un texto explicando por qué no puede, o el JSON envuelto en tres frases de cortesía. El paso siguiente lo acepta porque es una cadena de texto y él esperaba una cadena de texto. A partir de ahí todo el flujo trabaja sobre basura, con total normalidad. Se cubre con una validación de forma antes de seguir: si no cumple el formato esperado, se para y escala. La guía del humano en el bucle desarrolla dónde poner esa red según lo que cuesta el error.
4. El flujo que dejó de ejecutarse
El más tonto y el más frecuente. Nadie lo rompió: se desactivó al cambiar de plan, caducó una credencial de OAuth, alguien lo pausó para probar un jueves y no lo volvió a activar. No hay ejecución, luego no hay error, luego no hay nada que alertar. Este no se detecta mirando lo que pasa. Se detecta echando en falta lo que no pasa.
Qué alertar y qué callar: la alarma que suena siempre no la escucha nadie
El error contrario a no tener alertas es tenerlas todas. Un canal que recibe cuarenta avisos al día deja de ser un canal de alertas a la segunda semana: se silencia, se archiva o se ignora, y el día que llega el aviso que importaba está entre otros treinta y nueve. La fatiga de alertas no es un problema de la gente; es un problema de diseño.
La regla que aguanta en producción es de una línea: alerta solo lo que va a hacer que alguien deje lo que está haciendo. Todo lo demás no desaparece, se va a un panel que se revisa una vez al día con el café.
- Alerta a una persona: el flujo crítico falló de verdad; el flujo crítico lleva más tiempo del normal sin ejecutarse; la cola de excepciones crece dos días seguidos; el gasto del día se sale de su rango.
- Al panel diario: errores puntuales que se resolvieron al reintentar, casos escalados a revisión humana, ejecuciones más lentas de lo habitual, avisos de límite de plan que aún no aprietan.
- Ni a un sitio ni a otro: todo lo que nadie va a mirar nunca. Si un aviso no tiene un dueño y una acción posible, no es una alerta: es un log. Déjalo en los logs.
Empieza corto. Dos alertas por flujo crítico —falló, y dejó de ejecutarse— y solo añades una tercera cuando un incidente real demuestre que faltaba. Las alertas se ganan el sitio; no se reparten por si acaso.
El latido: cómo detectar el flujo que dejó de ejecutarse
Esta es la pieza que casi nadie tiene y la que más veces salva. Un latido es una alerta que suena cuando NO pasa algo. El flujo manda una señal cada vez que termina bien; un servicio externo la espera; si no llega dentro de la ventana esperada, avisa.
Dos detalles que deciden si funciona. El primero: el latido tiene que vivir fuera de la herramienta que estás vigilando. Si el vigilante y el vigilado son el mismo sistema, el día que se caiga el sistema no te avisa nadie —y ese es justo el día en que lo necesitas—. El segundo: la ventana se calibra con el ritmo real del flujo, no con el ideal. Un flujo que corre cada quince minutos puede permitirse una hora de margen; uno diario, no debería avisar por llegar veinte minutos tarde. Ventanas mal puestas producen falsas alarmas, y las falsas alarmas producen alertas silenciadas.
Confirmación de cierre: que el último paso demuestre que el trabajo llegó
El latido te dice que el flujo corrió. No te dice que hiciera algo útil. Para eso está la confirmación de cierre: el último paso de cada flujo crítico no es la acción, es la comprobación de la acción.
- Cuenta lo que entró y lo que salió. Si entraron catorce registros y se crearon cero, no es un día tranquilo: es un fallo. Un flujo que procesa cero elementos varios días seguidos merece una mirada, no un visto bueno.
- Comprueba en el destino, no en la respuesta. Que la API dijera que sí no prueba que el registro exista. Una lectura de vuelta —pedirle al sistema de destino el registro que acabas de crear— convierte una suposición en un hecho.
- Reconcilia con cadencia. Una vez al día, compara el origen con el destino y busca lo que falta. Es lo único que detecta el evento que nunca llegó, porque un webhook perdido no genera ningún error: genera una ausencia.
- Deja el rastro. Cada ejecución con su identificador, qué entró, qué salió y bajo qué versión. Sin eso no puedes reconstruir un caso concreto cuando alguien pregunta por él tres semanas después; ahí entra la gobernanza y control de la automatización con IA.
Qué pasa cuando salta: severidad, dueño y la regla de las tres veces
Una alerta sin destinatario es una notificación. Antes de encender nada, escribe tres cosas por flujo crítico: quién responde (una persona, no un departamento), qué se hace mientras se arregla (el plan manual: seguir facturando a mano no es un fracaso, es el plan) y qué justifica llamar a alguien fuera de horario. Casi nada lo justifica; conviene decidirlo en frío y no a las 23:40.
Y una regla que ahorra muchos incidentes futuros: si el mismo fallo salta tres veces, deja de arreglarse y pasa a rediseñarse. Un error que se repite no es mala suerte, es una suposición equivocada en el diseño del flujo —un caso que no se contempló, una API que no es tan fiable como se creía, un formato que cambia más de lo que se asumió—. Parchear la tercera vez solo garantiza que habrá una cuarta.
Nada de esto es caro. Un latido externo, una confirmación de cierre y dos alertas bien elegidas se montan en una tarde por flujo, y son la diferencia entre enterarte tú y enterarte por un cliente. Lo que sí cuesta es sostenerlo cuando tienes veinte flujos vivos y nadie cuyo trabajo sea mirarlos: eso ya no es montar automatizaciones, es operarlas —y es exactamente lo que hacemos en automatización de operaciones—. Si aún estás decidiendo qué automatizar y con qué, vuelve al pillar de automatizar con IA; si ya lo tienes montado, empieza por el flujo que más daño haría fallando en silencio.