Mi automatización dejó de funcionar: auditoría en 20 puntos

Si tu automatización dejó de funcionar, antes de arreglarla tienes que saber cuatro cosas: dónde corre, quién la paga, qué credencial usa cada paso y a quién le llegan los avisos. Sin esas cuatro respuestas, cualquier arreglo es a ciegas y el siguiente fallo llega igual. Lo he visto muchas veces: un flujo de Make, Zapier o n8n que alguien montó, funcionó meses y un lunes de septiembre aparece parado, sin error visible y con el proveedor en silencio. Este artículo es el protocolo que uso para auditar una automatización heredada: 20 puntos que se comprueban en una tarde, una tabla con las cinco causas de rotura silenciosa y el síntoma que delata a cada una, y un veredicto al final, arreglar, migrar o tirar. Es la pieza de urgencias de la guía para automatizar procesos con IA: aquella explica cómo nacen bien; esta, qué hacer con las que ya tienes.

Mi automatización dejó de funcionar: qué hacer en los primeros 15 minutos

Cuando una automatización deja de funcionar, lo primero es no tocar nada y fijar lo que hay: captura del error, fecha de la última ejecución correcta, plataforma y cuenta en la que corre, y quién ha recibido el aviso, si es que alguien lo ha recibido. Con eso se decide si es un fallo de credencial, de plan o de datos. Arreglar antes de mirar borra las pistas.

El orden importa, porque cada paso descarta una causa antes de pasar al siguiente:

1. Congela la escena. Captura de pantalla del error tal cual, con hora. No reejecutes, no reconectes, no edites. Si el flujo llevaba días parado, el historial es la única prueba de qué pasó, y ese historial caduca.
2. Busca la última ejecución correcta. En n8n, la lista de ejecuciones; en Make, el historial del escenario; en Zapier, el Zap history. La fecha te dice si la rotura fue ayer o hace tres semanas, y eso cambia el diagnóstico entero.
3. Mira si está apagada, no rota. Make puede desactivar un escenario tras varios errores seguidos, y si el escenario arranca con un disparador instantáneo lo desactiva al primer error, según su documentación de ajustes de escenario (2026). Un interruptor en OFF se enciende; no se repara.
4. Comprueba la credencial del paso que falla. Un mensaje de "reconectar cuenta" o un error 401 apuntan a un token caducado. Antes de reconectar, apunta de quién era esa cuenta: lo vas a necesitar en el punto 5 del protocolo.
5. Revisa el plan y la facturación. Créditos agotados, tarjeta rechazada o plan degradado paran flujos sin lanzar un solo error de programación. Busca en el correo de la empresa las facturas de la plataforma.
6. Localiza a quién llegó el aviso. Si nadie lo recibió, ya tienes el primer punto rojo de la auditoría, aunque el arreglo de hoy sea trivial.

Con esos seis pasos sabes si estás ante un token, un plan, un interruptor o algo peor. Lo que no sabes todavía es si merece la pena arreglarlo, y para eso está el resto del artículo.

Por qué mi automatización dejó de funcionar sola: las 5 causas de rotura silenciosa

Una automatización se rompe sola porque depende de piezas ajenas con calendario propio: credenciales que caducan, versiones de API y modelos de IA que se retiran, datos de entrada que alguien cambia, planes que se agotan y plataformas que desactivan un flujo tras varios errores. Ninguna de las cinco necesita que alguien toque el flujo, y tres de ellas no producen ningún error visible.

Lo silencioso es lo que las hace caras. Esta es la tabla que uso para poner nombre al fallo antes de tocar nada: cada causa tiene un síntoma que la delata y un sitio concreto donde confirmarla.

Dos filas merecen leerse despacio. La primera está en la documentación de OAuth 2.0 de Google (2026): un proyecto con la pantalla de consentimiento en estado Testing recibe tokens de refresco que caducan a los 7 días, y cualquier token sin uso durante seis meses deja de valer. Muchas automatizaciones baratas se conectan a Gmail o a Sheets con una aplicación que nunca salió de ese estado de prueba, y se rompen cada semana hasta que alguien pregunta por qué. La segunda está en la política de versiones de la Graph API de Meta (2026): cada versión vive al menos dos años y, cuando caduca, las llamadas no fallan: se redirigen a la versión más antigua disponible. El flujo sigue en verde. Lo que cambia es lo que devuelve.

Los modelos de IA que llama el flujo van por el mismo camino. Anthropic avisa con al menos 60 días antes de retirar un modelo y las peticiones a un modelo retirado fallan, según su página de deprecaciones (2026); OpenAI da al menos 6 meses para los modelos de disponibilidad general y tan poco como 2 semanas para los modelos en vista previa, según su política de deprecaciones (2026). Si nadie de tu empresa recibe esos correos porque la cuenta es del proveedor, el aviso existió y nadie lo leyó.

Nadie rompió nada. Caducó.

¿Cómo auditar las automatizaciones que ya tienes? El protocolo de 20 puntos

Auditar una automatización heredada es responder veinte preguntas en cinco bloques: propiedad y dinero, credenciales, ejecución y avisos, datos y dependencias, y documentación y salida. Cada respuesta es verde o roja, sin grises. Lo que sale es un mapa de dónde está el riesgo, y al final del artículo ese mapa se convierte en veredicto: arreglar, migrar o tirar.

Se hace con acceso de administrador a la plataforma y el correo de la empresa abierto en otra pestaña. Una tarde para un flujo; un día para una decena. Si un punto no se puede comprobar porque nadie te da acceso, cuenta como rojo: la falta de acceso es el hallazgo.

Cuenta los rojos por bloque, no en total. Cuatro rojos repartidos son mantenimiento pendiente; cuatro rojos en propiedad son otro problema, y no es técnico. Los puntos 1 a 4 son los que más pesan: si salen rojos, el resto de la auditoría describe un flujo que no es tuyo.

Los puntos 6, 7, 12, 13, 14 y 20 tienen respuesta publicada por las propias plataformas. Van en las dos secciones siguientes, con la fuente y el número exacto, porque son los que el proveedor suele contestar con un "eso no pasa".

¿Qué pasa si caduca un token y nadie se entera?

Si caduca un token y nadie se entera, la automatización se para en silencio y el negocio sigue como si funcionara: los correos no salen, los pedidos no se registran y nadie lo sabe hasta que un cliente pregunta. Cuánto dura ese silencio no depende del token, sino de tres ajustes que casi nadie revisa: el flujo de error, los reintentos y a quién llega el aviso.

Empecemos por el token, porque tiene calendario. La documentación de OAuth 2.0 de Google (2026) enumera cuándo deja de funcionar un token de refresco: si la app está en estado Testing (caduca a los 7 días), si lleva seis meses sin usarse, si el usuario cambia la contraseña y el token incluye permisos de Gmail, o si esa cuenta supera el límite de 100 tokens de refresco por cliente OAuth. Cuatro formas de morir, ninguna con aviso previo. Meta, en su guía de tokens de acceso (2026), dice que los tokens de usuario de larga duración viven unos 60 días, y añade una frase que debería ir enmarcada en cualquier auditoría: no dependas de que esas duraciones se mantengan, pueden cambiar sin aviso o caducar antes.

Ahora el silencio, plataforma por plataforma.

En n8n, un flujo solo avisa si tiene un flujo de error asignado en sus ajustes. Según la documentación de manejo de errores de n8n (2026), ese flujo de error empieza con el nodo Error Trigger, el mismo puede servir a muchos flujos a la vez y no se puede probar en ejecuciones manuales: solo salta cuando falla una ejecución automática. Si nadie lo configuró, el fallo se guarda en el historial y ahí se queda, esperando a que alguien entre a mirar.

En Make, el almacenamiento de ejecuciones incompletas está desactivado por defecto y se activa escenario a escenario, según su página de ejecuciones incompletas (2026). Sin ese ajuste, el dato del pedido que falló no se guarda para reintentarlo: se pierde. Y el ajuste de errores consecutivos decide cuántos fallos seguidos tolera Make antes de apagar el escenario; con disparador instantáneo, ninguno.

En Zapier, el reintento automático existe desde el plan Professional y funciona bien, pero tiene un efecto secundario que nadie lee: según su documentación de Autoreplay (2026), reintenta el paso hasta 5 veces con esperas de 5 minutos, 30 minutos, 1 hora, 3 horas y 6 horas, y no envía ningún correo de error hasta que falla el último intento. Sumadas las esperas, el primer aviso de un fallo persistente llega más de diez horas después del primer error. Si el flujo cobra pedidos, son diez horas de pedidos sin cobrar.

Y queda el historial, que es la memoria de la auditoría. Zapier garantiza como máximo 60 días de datos de ejecución y muestra hasta 10.000 ejecuciones, según su página de historial de Zaps (2026). Un n8n autoalojado con la configuración por defecto borra las ejecuciones con más de 336 horas, es decir, 14 días, y también las que sobran por encima de las 10.000 más recientes, según su documentación de gestión de datos de ejecución (2026). Si revisas el flujo una vez al mes, la mitad de lo que pasó ya no existe cuando llegas.

¿Se puede exportar mi automatización y llevármela?

Sí, en las tres plataformas se puede exportar la lógica del flujo en JSON: n8n descarga el workflow, Make exporta un blueprint del escenario y Zapier permite descargar todos los Zaps desde los ajustes de la cuenta. Lo que no viaja en ninguna de las tres son las conexiones: las credenciales hay que volver a crearlas en el destino. Exportar te da el plano, no las llaves.

Los detalles cambian de una a otra, y conviene saberlos antes de pedir el export al proveedor, porque es la petición que revela cómo va a acabar la relación.

En n8n, la exportación (2026) descarga el flujo como JSON desde el menú del editor, y ese fichero incluye los nombres e identificadores de las credenciales, no los secretos. Si el n8n es autoalojado hay una capa más: la guía de copia y restauración de n8n (2026) explica que las credenciales se guardan cifradas y que, sin la clave de cifrado del fichero de configuración, una base de datos restaurada no se puede descifrar. Es el punto 20 del protocolo y el que más veces sale rojo: hay copia de los flujos y nadie sabe dónde está la clave. Sin ella, la copia sirve para leer el flujo, no para arrancarlo.

En Make, el blueprint (2026) se exporta desde el menú de tres puntos del editor como fichero JSON e incluye módulos, ajustes y mapeos; las conexiones a cada cuenta hay que crearlas de nuevo después de importarlo. En Zapier, la exportación de datos de la cuenta (2026) genera un fichero JSON con todos los Zaps no borrados y los datos necesarios para ejecutar cada uno; llega por correo dentro de un ZIP.

¿Y si el flujo vive en la cuenta del proveedor? Entonces exportar no depende de la plataforma, depende de él. Pide el JSON por escrito, con fecha. Si llega, tienes el plano y puedes reconstruir las llaves. Si no llega en dos semanas, tienes la respuesta al punto 4 y a casi todo lo demás.

Lo que aprendí operando n8n en producción

Operar n8n autoalojado en producción enseña cosas que no vienen en ningún tutorial: que el flujo de error se configura el mismo día que el flujo, que los valores por defecto de retención están pensados para ahorrar disco y no para auditar, y que una copia de seguridad sin la clave de cifrado es un dibujo. Todo eso sale de mantener procesos propios, no de leer documentación.

El caso que más me ha enseñado es Patitas: un asistente de IA que responde con datos reales del negocio y cobra online sin que intervenga una persona. Cuando un flujo cobra, un fallo silencioso significa dinero que no entra y un cliente que cree que ha pagado. Por eso allí la regla es que ningún flujo entra en producción sin su flujo de error asignado ese mismo día, con el aviso llegando a un canal que miro, no a un buzón de administración. La regla existe porque antes no existía. Y en la documentación de n8n hay un detalle que explica por qué tanta gente cree que lo tiene configurado y no lo tiene: el Error Trigger no salta en ejecuciones manuales. Lo pruebas a mano, ves que no avisa y asumes que es normal.

La segunda lección es de retención. Con los valores por defecto, n8n autoalojado borra las ejecuciones de más de 14 días y las que exceden las 10.000 más recientes. Para un servidor de pruebas es sensato; para auditar un flujo que revisas cada mes es demasiado poco, porque cuando te sientas a mirar el fallo del día 3 ya no está. Yo lo subo en cualquier instancia que cobre o registre pedidos, y etiqueto las ejecuciones que quiero conservar: las anotadas no se borran nunca, según la misma página de gestión de datos de ejecución (2026).

La tercera es la clave. Una copia de la base de datos de n8n sin el fichero de configuración que guarda la clave de cifrado restaura los dibujos de los flujos y ninguna credencial. Se comprueba restaurando en un servidor limpio, no leyendo que la copia existe.

Y una opinión con la que puedes discrepar: si tu flujo tiene tres pasos, lo montaste tú y no mueve dinero, la mitad de este protocolo te sobra. Pasa los puntos 1, 5, 10 y 20 y sigue con tu vida. El protocolo completo es para lo que hizo otro o para lo que cobra.

Mi automatización dejó de funcionar: ¿la arreglo, la migro o la tiro?

Se arregla cuando el proceso sigue siendo el mismo, el fallo está en un punto concreto y tienes acceso para tocarlo. Se migra cuando el flujo vale pero vive en cuenta ajena, en una plataforma que no encaja o en un plan que se agota cada mes. Se tira cuando el proceso cambió, nadie puede entrar o entenderlo cuesta más que rehacerlo. Lo que costó montarla no cuenta.

El veredicto sale de los rojos por bloque, no del total:

• Arreglar: rojos solo en credenciales o en ejecución y avisos (puntos 5 a 14), con los cuatro primeros en verde. Es lo más habitual y lo más barato: se reconecta, se pone la credencial a nombre de la empresa, se configura el flujo de error y se sube la retención. Una tarde.
• Migrar: el proceso es válido y el flujo funciona, pero los puntos 1 a 4 salen rojos (vive en cuenta ajena) o el 18 se repite cada mes (la unidad que cobra la plataforma no encaja con tu volumen). Se exporta el plano, se reconstruyen las llaves en una cuenta propia y, si toca cambiar de herramienta, la comparativa de n8n, Make y Zapier tiene la tabla de qué cobra cada una.
• Tirar: el punto 17 revela que el proceso ya no es ese, el 19 y el 20 son rojos a la vez (ni documentación ni export) y nadie sabe explicar qué hace cada paso. Rehacer sobre un mapa del proceso sale más barato que hacer arqueología, y esta vez nace con propiedad, avisos y mantenimiento pactado.

Un caso que engaña: el flujo está roto por un token (arreglar), pero el token es del proveedor que no contesta (migrar). Gana el rojo de propiedad. Arreglar sobre cuenta ajena es pagar por prolongar el problema.

Quien decide arreglar o migrar hereda el trabajo de mantenerlo, y ese trabajo tiene nombre, horas y contrato, o no existe: cómo exigirlo por escrito está en la guía de mantenimiento de automatizaciones, la gemela de esta pieza. Y si después del veredicto la duda es más de fondo, si la automatización merecía existir, ese examen está en por qué la IA no da resultados.

Este protocolo lo puedes pasar solo con lo que hay aquí. Si prefieres pasarlo conmigo, en Godius, agencia de inteligencia artificial aplicada a empresas reales, la auditoría de automatizaciones heredadas es una puerta de entrada habitual de los servicios de automatización: llega alguien con un flujo parado y un proveedor en silencio, y el trabajo empieza por recuperar el control. Te lo digo desde el principio: el veredicto puede ser tirar, y si lo es, también te lo diré.