Las automatizaciones que fallan en silencio son flujos que dejan de hacer su trabajo sin generar ningún error visible: siguen “funcionando” para la herramienta, pero no crean el contacto, no envían el email o lo duplican. El daño no está en el fallo, sino en el tiempo que pasa hasta que alguien, normalmente un cliente, lo descubre.
Esta es una frase que repito mucho: el problema de muchas automatizaciones no es que fallen. Es que nadie sabe que han fallado.
Una automatización que se rompe del todo es casi una buena noticia. Todo se para, alguien se queja en una hora y se arregla. La que de verdad hace daño es la que falla a medias durante tres semanas: los leads de un canal que no llegan al CRM, el acceso al curso que no se activa para quien pagó con un método concreto, la factura que se genera dos veces. Nadie ve un error. Solo ves, mucho después, las consecuencias.
¿Por qué fallan en silencio las automatizaciones de un negocio digital?
Porque casi todas se construyen para el caso feliz. Alguien monta un flujo en n8n, Make o Zapier, lo prueba con dos registros, funciona y pasa a otra cosa. El flujo no tiene logs propios, nadie es responsable de él y nadie ha pensado qué debería pasar cuando algo cambia fuera de la automatización. Es la diferencia entre conectar dos herramientas y automatizar un proceso de verdad.
Y fuera de la automatización las cosas cambian constantemente. Estos son los fallos silenciosos que más veo:
| Tipo de fallo | Qué ocurre | Por qué nadie se entera |
|---|---|---|
| Credencial caducada | Un token de acceso a una API expira o alguien cambia una contraseña | Según la herramienta, el flujo puede quedar pausado o fallar sin que nadie mire el panel |
| Cambio de campo en un formulario | Alguien renombra “Teléfono” por “Móvil” | El flujo sigue ejecutándose, pero envía el campo vacío |
| Límite de una API | Un pico de volumen supera el límite de peticiones | Parte de las ejecuciones se descartan o se retrasan |
| Webhook que no llega | El sistema de origen no envía el aviso, o lo envía y el destino no responde | Si no hay ejecución, no hay error que registrar |
| Ejecución a medias | El flujo crea el contacto pero falla al darle acceso | El registro existe, así que parece que todo fue bien |
| Duplicados por reintento | Un reintento repite un paso que ya se había hecho | No hay error: hay dos emails, dos cargos o dos contactos |
Fíjate en la columna de la derecha. En la mayoría de casos la herramienta no tiene forma de saber que algo va mal, porque desde su punto de vista no ha pasado nada raro. Por eso “tenemos las notificaciones de errores activadas” no es una respuesta suficiente.
¿Cuánto cuesta una automatización que falla sin avisar?
No voy a darte una cifra, porque depende por completo de qué proceso toque. Pero sí puedo darte la forma de calcularlo, que es la que usamos en FCG Systems antes de proponer nada: cuántos registros pasan por ese flujo, qué vale cada uno, cuánto tarda de media en detectarse un fallo y cuántas horas cuesta después reconstruir lo que se perdió.
En un negocio que vende por lanzamientos o que capta leads a diario, el tiempo de detección es la variable que más pesa. Un flujo que falla un martes y se descubre el viernes no pierde “un error”: pierde tres días de registros, de accesos o de seguimiento comercial. Si además esos datos no se pueden reconstruir, el coste ya no es de horas, es de clientes.
Hay un coste menos visible: la confianza. Cuando el equipo descubre dos o tres veces que “la automatización no funcionaba”, empieza a comprobarlo todo a mano. Y en ese momento has pagado la automatización y sigues haciendo el trabajo manual.
¿Qué significa que un sistema sea observable?
Un sistema observable es el que te dice, sin que tengas que ir a buscarlo, si está haciendo su trabajo. No es una herramienta concreta. Es una forma de construir que se puede aplicar a un flujo de Make igual que a un servicio propio en un servidor.
En FCG Systems tenemos una regla técnica que no negociamos: un proceso crítico sin logs no está terminado. Da igual que funcione en la demo. Si no puedes saber qué hizo ayer, no lo puedes operar.
Estas son las piezas que hacen observable una automatización:
Logs que cuentan lo que pasó con cada registro
No basta con el historial de ejecuciones de la herramienta, que suele conservarse un tiempo limitado y es difícil de consultar. Un log útil guarda, para cada operación, qué registro entró, qué pasos se completaron, cuál falló y por qué. Puede vivir en una tabla de Postgres, en Airtable o en el sistema que ya uséis, siempre que se pueda consultar.
Alertas con dueño
Una alerta que llega a un canal donde la leen cinco personas no la atiende nadie. Cada alerta tiene que tener un responsable y una severidad. Y tiene que ser poco ruidosa: si salta diez veces al día por cosas sin importancia, en una semana todo el mundo la ignora.
Reintentos idempotentes
Reintentar es necesario, porque las APIs fallan de forma temporal. Pero un reintento sin idempotencia es la receta perfecta para duplicados. La idempotencia consiste en que ejecutar dos veces la misma operación produzca el mismo resultado que ejecutarla una: antes de crear, compruebas si ya existe; antes de cobrar, usas un identificador único de operación.
Reconciliación diaria
Es la pieza que más fallos silenciosos destapa y la que menos se implementa. Consiste en comparar, una vez al día, lo que entró en el origen con lo que llegó al destino: formularios recibidos contra contactos creados, pagos contra accesos activados. Si los números no cuadran, hay un fallo aunque ninguna herramienta haya marcado error.
Cola de errores
Cuando algo falla definitivamente, después de los reintentos, el registro no puede desaparecer. Va a una cola de errores (lo que en ingeniería se llama dead letter queue): un lugar donde se guarda con su contexto para revisarlo y reprocesarlo cuando se corrija la causa.
Heartbeat
Algunos fallos no producen ejecuciones con error, producen ausencia de ejecuciones. Un heartbeat es una comprobación de vida: si un flujo que normalmente se ejecuta cada hora lleva seis sin hacerlo, salta una alerta. Es la única forma de detectar el webhook que nunca llega.
¿No es suficiente con los avisos de error de n8n o Make?
Son un buen punto de partida y conviene activarlos. n8n, por ejemplo, permite definir un flujo de error que se ejecuta cuando otro falla, y Make permite añadir rutas de gestión de errores dentro de cada escenario.
Pero cubren solo una parte de la tabla de antes: las ejecuciones que la herramienta reconoce como fallidas. No detectan el campo que llega vacío, el webhook que nunca se disparó ni el duplicado que genera un reintento. Para eso necesitas comprobaciones que miren el resultado de negocio, no el estado técnico de la ejecución. Si el fallo concreto es un webhook que no entra en n8n, las causas habituales están en por qué un webhook de n8n no funciona; cómo gestiona los errores cada herramienta, en la comparativa n8n vs Make.
Mi opinión es que el aviso de error de la herramienta es el detector de humo. La reconciliación y el heartbeat son quien comprueba que la casa sigue en pie.
¿Qué hacer cuando salta una alerta?
Clasificarla. No todo fallo merece despertar a nadie, y tratar todo como urgente es la forma más rápida de que nada lo sea. Usamos la misma clasificación de severidad para automatizaciones que para cualquier otro sistema:
| Nivel | Qué significa | Ejemplo en automatización |
|---|---|---|
| P1 | Sistema crítico caído | Los registros de un lanzamiento no llegan a ningún sitio |
| P2 | Función importante degradada | Los leads llegan al CRM, pero sin asignar a ningún comercial |
| P3 | Bug no crítico | Un campo secundario llega con formato incorrecto |
| P4 | Mejora o petición | Añadir un dato nuevo a la notificación del equipo |
Una aclaración honesta: los tiempos de respuesta dependen del acuerdo con cada negocio. No existe soporte instantáneo por defecto, y quien lo promete sin contrato y sin capacidad reservada suele acabar incumpliéndolo. Lo que sí debe existir siempre es claridad sobre quién atiende cada nivel.
¿Quién es responsable de una automatización cuando falla?
Esta pregunta incomoda, y por eso es importante. En muchos negocios la respuesta real es “la persona que la montó”, que a veces ya no está o que tiene otras veinte cosas. Cuando el conocimiento de un flujo crítico vive en la cabeza de una sola persona, el fallo silencioso se convierte en fallo permanente. Hablo de ese problema en el artículo sobre la dependencia de una persona y cómo tener capacidad técnica sin un departamento.
El ownership de una automatización incluye tres cosas: saber que existe y qué hace (documentación), saber cuándo falla (observabilidad) y tener capacidad para arreglarla (mantenimiento). Si falta una, el flujo está huérfano aunque funcione.
Esto conecta con una idea más amplia: las automatizaciones no son piezas sueltas, son parte de un sistema. Si quieres ver cómo encajan con el software, los datos y la infraestructura, lo explico en la guía de sistemas para negocios digitales. Y si tus fallos se concentran en el paso del formulario al comercial, te interesa el artículo sobre leads que se pierden y Excel como CRM.
Checklist: ¿tus automatizaciones fallan en silencio?
Repasa tus flujos críticos con estas preguntas. Cada “no” es un punto ciego.
- ¿Tienes una lista de todas las automatizaciones activas, con qué hace cada una y quién es su responsable?
- ¿Sabes cuáles son críticas, es decir, cuáles cuestan dinero o clientes si fallan?
- ¿Cada flujo crítico guarda un log consultable por registro, no solo el historial de la herramienta?
- ¿Las alertas de error llegan a una persona concreta, con severidad definida?
- ¿Los reintentos son seguros, o un reintento puede duplicar contactos, emails o cobros?
- ¿Comparas cada día lo que entra en el origen con lo que llega al destino?
- ¿Los registros que fallan definitivamente van a una cola de errores en lugar de perderse?
- ¿Tienes alertas cuando un flujo lleva demasiado tiempo sin ejecutarse?
- ¿Sabes qué credenciales y tokens caducan, y cuándo?
- ¿Alguien revisa qué automatizaciones se rompen si cambia un formulario o un campo del CRM?
- ¿Las credenciales están gestionadas en un gestor de secretos y no pegadas en un documento o un chat?
- ¿Podrías reconstruir los datos de la última semana si un flujo hubiera fallado sin avisar?
¿Por dónde empiezo si mis automatizaciones no son observables?
Por las críticas, no por todas. Elige los dos o tres flujos que más te dolería que fallaran (captación, pagos y accesos suelen estar ahí), y añade primero la reconciliación diaria y las alertas con dueño. Son las dos piezas que más fallos silenciosos destapan con menos esfuerzo.
Si prefieres que lo hagamos nosotros, en FCG Systems lo resolvemos como parte de nuestro servicio de automatización de procesos: un Automation Sprint de 1 a 3 semanas para rehacer o reforzar un flujo concreto con logs, pruebas, documentación y handoff. Cuando la fiabilidad depende también de servidores, bases de datos o backups, lo conectamos con infraestructura y DevOps.
Si tienes la sospecha de que algo lleva tiempo fallando sin que nadie lo vea, cuéntame qué proceso os está frenando y lo miramos juntos.
Preguntas frecuentes
¿Cómo sé si una automatización está fallando sin avisar?
La forma más fiable es comparar lo que entra con lo que sale. Si cada día cuentas los registros de origen y los que llegaron al destino, cualquier diferencia te avisa aunque la herramienta no haya marcado ningún error. A eso se suma una alerta cuando un flujo lleva demasiado tiempo sin ejecutarse.
¿n8n, Make o Zapier tienen alertas de errores?
Sí, las tres permiten enterarte de ejecuciones con error, por ejemplo n8n con flujos de error dedicados. El problema es que solo detectan lo que la herramienta reconoce como fallo. Un formulario que cambia un campo o un webhook que nunca llega no generan un error visible, y por eso hacen falta comprobaciones propias.
¿Qué significa que una automatización sea idempotente?
Que puedes ejecutarla dos veces con el mismo dato sin provocar efectos duplicados. Si un reintento vuelve a crear el mismo contacto o a enviar el mismo email, el flujo no es idempotente. Se consigue comprobando si el registro ya existe o usando un identificador único por operación.
¿Hace falta rehacer todas las automatizaciones para hacerlas observables?
Normalmente no. Lo habitual es empezar por los procesos críticos, los que cuestan dinero o clientes si fallan, y añadirles logs, alertas con responsable, reintentos seguros y una reconciliación diaria. El resto puede esperar a una segunda fase.
