Tu workflow de n8n falla, qué hacer en la próxima hora (2026)

Automatización

14 de octubre de 202614 min read

Miguel Ángel Rodríguez (Miguelo DEV)Especialista en automatización de procesos con n8n

Hay dos formas de enterarte de que una automatización lleva tres días rota. Una es mirar el panel. La otra, la de siempre, es que te lo diga un cliente preguntando por un pedido que nunca llegó.

Cuando eso pasa, la reacción natural es abrir n8n y empezar a tocar nodos. Es justo lo que no hay que hacer. Casi todos los fallos de n8n caen en seis patrones y cada uno se diagnostica mirando un sitio concreto, en un orden concreto. Esta guía es ese orden.

Qué mirar en los primeros 15 minutos cuando un workflow de n8n falla

Antes de tocar un solo nodo, decide si hay que parar el flujo. Es la única decisión irreversible de todo el proceso y se contesta con una pregunta. Si el flujo se vuelve a ejecutar ahora mismo, ¿puede duplicar algo que ya se hizo? Si mueve pedidos, facturas, cobros o correos a clientes, pausa primero y diagnostica después. Si solo lee y escribe en una hoja interna, déjalo correr.

Después van cuatro comprobaciones, siempre en este orden.

Primera, el historial de ejecuciones y no el editor. El editor te enseña cómo está el flujo hoy. El historial te enseña qué pasó de verdad el día que falló, con el dato exacto que entró en cada nodo. Son dos cosas distintas y la segunda es la que resuelve.

Segunda, cuándo fue la última ejecución buena. Esa fecha es tu mejor pista y casi nadie la mira. Si la última buena fue el martes por la noche, la pregunta ya no es qué falla, es qué cambió el miércoles. Una credencial renovada, una actualización, un despliegue del proveedor, un campo nuevo en el formulario.

Tercera, el dato de entrada de la primera ejecución mala frente al de la última buena. Ponlos uno al lado del otro. En la mitad de los casos el flujo está perfecto y lo que cambió fue la forma del dato. Un campo que ahora llega vacío, un importe que viene como texto, un acento donde antes no había nada.

Cuarta, si el fallo es de todas las ejecuciones o de algunas. Si fallan todas, mira la conexión, la credencial o la versión. Si falla una de cada veinte, mira los límites de peticiones y los tiempos de espera. Son dos investigaciones completamente distintas y confundirlas cuesta la tarde.

Por qué un workflow de n8n aparece en verde y no ha hecho nada

Porque alguien activó el modo continuar en caso de error para que dejara de saltar la alerta. Con esa opción el nodo falla, el error viaja al siguiente paso como si fuera un dato normal y la ejecución se cierra marcada como correcta.

Lo cuento el primero porque es el fallo más caro del catálogo. No por difícil, sino porque no genera ninguna señal. El flujo lleva tres semanas sin escribir en el CRM y el panel está impecable.

Hay un segundo efecto que casi nadie conoce y que es el que de verdad duele. Si el nodo continúa, el flujo de errores no se dispara. Para n8n no ha habido error, así que no hay nada que notificar. Mucha gente tiene montado su flujo de errores, lo tiene conectado y cree estar cubierta, cuando en realidad lo ha dejado mudo con esa casilla.

Y un tercero, por si acabas de montar el flujo de errores para probar todo esto. No se puede probar a mano. Su disparador solo salta en ejecuciones automáticas, nunca en las que lanzas desde el editor. Mucha gente lo da por roto cuando funciona, y mucha otra lo da por bueno sin haberlo visto saltar jamás.

La forma correcta de usar el modo continuar es con salida de error separada, enviando esa rama a un sitio donde alguien la mire. Lo que no vale es usarlo como botón de silencio. Eso no apaga el fuego, apaga la alarma de incendios.

Qué significa cada error de n8n y cuál se arregla reintentando

La regla corta es que se reintenta lo que depende del otro lado y no se reintenta lo que depende de ti. Un proveedor saturado se recupera solo. Una credencial caducada o un campo mal formado, no.

Sobre el reintento conviene saber dónde está el techo. La opción de reintentar al fallar está limitada a cinco intentos y a cinco segundos de espera, y esa espera es fija. No existe espera creciente nativa, por mucho que circule lo contrario en tutoriales. Quien necesita una espera que vaya doblando la construye aparte con un nodo de pausa y un bucle.

Y sobre el 401 hay un matiz que ahorra media hora de búsqueda. Una credencial la suelen compartir varios flujos, así que cuando caduca no se rompe uno, se rompen cuatro, y tres de ellos en silencio porque nadie los estaba mirando. Por qué caducan y cada cuánto hay que revisarlas lo desarrollo en cuánto cuesta mantener automatizaciones de n8n al mes.

Por qué un webhook de n8n deja de recibir datos sin que nadie haya tocado nada

Nueve de cada diez veces estás mirando la URL de prueba y no la de producción. Son dos direcciones distintas, con rutas distintas, y la de prueba solo escucha mientras tienes el editor abierto con el nodo en modo escucha. En cuanto cierras la pestaña, deja de existir para el mundo.

Pasa sobre todo cuando alguien copió la URL durante el desarrollo, la pegó en el panel del proveedor y nunca la cambió. Funcionó durante las pruebas, funcionó la primera semana porque el editor estaba abierto media jornada, y dejó de funcionar el día que nadie entró en n8n.

Las otras tres causas, por frecuencia.

El flujo no está publicado. Desde la versión 2 los flujos se publican y ya no se activan, así que el botón no está donde la gente lo recuerda. Un flujo sin publicar no tiene webhook de producción vivo, por mucho que la URL aparezca en pantalla.

Alguien cambió el nombre de la ruta. Renombrar el camino del webhook en el nodo cambia la dirección entera. El proveedor sigue llamando a la antigua y recibe un 404 que tú no ves, porque ese error ocurre fuera de n8n y no genera ninguna ejecución.

El proveedor desactivó la suscripción. Casi todas las plataformas dejan de enviar tras acumular entregas fallidas seguidas. Si tu instancia estuvo caída una noche, puede que el webhook siga desactivado al otro lado aunque tú ya estés en pie. Eso se comprueba en el panel del proveedor, nunca en n8n.

Para distinguir si el problema es tuyo o suyo hay una prueba de treinta segundos. Lanza tú una petición a la URL de producción. Si aparece una ejecución, n8n está recibiendo bien y el problema está en quien debía llamarte. Si no aparece nada, el problema es tuyo y ya has descartado medio mapa.

Qué hacer cuando un workflow de n8n se queda a medias o se para sin error

Si no hay error es que no hubo tiempo de escribirlo, y eso casi siempre es memoria. n8n pasa todos los elementos en memoria de un nodo al siguiente. Un lote de ochenta mil filas, o un puñado de ficheros adjuntos arrastrados por media docena de pasos, tumban el proceso antes de que exista nada que registrar. La ejecución se queda colgada en marcha o desaparece sin dejar rastro.

Las tres salidas, en orden de esfuerzo.

Trocear con el nodo de lotes. Procesar de doscientos en doscientos en lugar de todo de golpe. Es el cambio más barato y el que más veces resuelve.

Dejar de arrastrar los binarios. Si descargas un fichero en el paso dos y lo subes en el paso nueve, ese fichero va en memoria por los siete pasos intermedios sin que nadie lo use. Separar el tratamiento del binario en un subflujo corta el problema de raíz.

Guardar los binarios en disco. Por defecto n8n los mantiene en memoria. Cambiar el modo de datos binarios a sistema de ficheros con N8N_DEFAULT_BINARY_DATA_MODE es una variable de entorno y un reinicio.

Hay un caso parecido que despista mucho y que no es un fallo. La ejecución no aparece en el historial porque no se guardó, no porque no ocurriera. n8n viene con la purga activada, con un tope de 336 horas de antigüedad y de 10.000 ejecuciones guardadas, y además se puede configurar para no guardar las ejecuciones correctas. Si estás buscando qué pasó hace tres semanas, es probable que ya no exista. Antes de dar por hecho que el flujo no corrió, comprueba qué política de guardado tiene la instancia.

Por qué un flujo que funcionaba se rompió justo después de actualizar n8n

Porque una actualización de n8n no es solo código, también toca la base de datos, y eso no se deshace cambiando la etiqueta de la versión. n8n aplica migraciones al arrancar y solo migra hacia delante.

Esto cambia por completo el plan de acción. Si el fallo empezó tras una actualización, la pregunta no es cómo vuelvo atrás, es tengo copia de seguridad de antes de actualizar. Si la tienes, el rollback es restaurarla. Si no la tienes, el único camino es hacia delante, arreglando lo que la nueva versión cambió.

El otro detalle que provoca estas sorpresas es no fijar la versión. Si la instancia corre siempre la última, cualquier reinicio del contenedor puede traerte una versión nueva sin que nadie lo haya decidido. Mucha gente descubre que ha actualizado justo cuando viene a investigar por qué algo dejó de funcionar.

Cómo evitar que el mismo fallo de n8n se repita el mes que viene

El objetivo no es que nada falle, es enterarte tú antes que tu cliente. Fallar van a fallar, porque dependes de APIs que cambian sin avisarte. Lo que se puede diseñar es cuánto tarda en saberse.

Cuatro piezas, por orden de lo que ahorran.

Un flujo de errores conectado a todos los flujos críticos. No a uno, a todos, y revisado uno por uno. Conectarlo cuesta un minuto por flujo y es lo que separa enterarte en cinco minutos de enterarte en tres semanas.

Avisos sobre el resultado y no sobre la ejecución. Que el flujo haya terminado no significa que haya hecho su trabajo. La alerta útil es la que salta cuando hoy se procesaron cero pedidos en una franja en la que siempre hay veinte, porque esa es la única que detecta el fallo silencioso del verde.

Una clave de idempotencia en todo lo que crea cosas. Si el flujo genera pedidos, facturas o correos, necesita comprobar si ya procesó ese identificador antes de hacer nada. Es lo que te permite reintentar con tranquilidad en lugar de rezar.

Un inventario de credenciales con su fecha de caducidad. Una hoja con qué credencial usa qué flujo y cuándo expira convierte una caída de tres semanas en un recordatorio de calendario.

Si alguna de las cuatro no está en tu proyecto, probablemente tampoco estaba en el presupuesto. Qué entregables hay que exigir para que sí estén lo detallo en contratar un desarrollador de n8n.

Cuándo puedes arreglarlo tú y cuándo te sale más caro seguir intentándolo

Te digo primero cuándo no hace falta que llames a nadie, aunque juegue en mi contra.

Si el error dice 401 y el flujo usa una integración nativa, reconecta la credencial y vuelve a lanzarlo. Se arregla en dos minutos y no necesitas a nadie.

Si falla una ejecución de cada veinte con un 429, baja el ritmo y activa el reintento. También es tuyo.

Si el webhook dejó de recibir, haz la prueba de los treinta segundos de más arriba antes que cualquier otra cosa. La mitad de las veces aparece la URL de prueba pegada en el panel del proveedor y se acabó el misterio.

Y ahora los cuatro casos en los que seguir probando sale caro.

Llevas más de dos horas y todavía no sabes qué cambió. El coste de una hora de alguien que ya ha visto ese error es menor que el de tu quinta hora a ciegas.

El flujo mueve dinero o datos de clientes y no sabes si ha duplicado algo. Aquí el riesgo ya no es el flujo parado, es el flujo corriendo mal. Pausa y pide ayuda.

Empezó justo tras actualizar y no tienes copia previa. Es el escenario con menos margen de todos y el que peor tolera la prueba y error.

Es el tercer parche sobre el mismo flujo en un mes. Esa es la señal clara. El problema ya no es el error, es el diseño, y seguir parcheando solo mueve el fallo de sitio.

Cómo rescato yo una instancia de n8n con flujos cayéndose

Lo primero que hago es no arreglar nada. Cuando alguien me llama con tres flujos caídos, la tentación es empezar por el que más ruido hace, y casi siempre es el síntoma y no la causa.

Congelo y mido antes de tocar. Pauso lo que puede duplicar, dejo corriendo lo que solo lee y anoto la hora de la última ejecución buena de cada flujo. Esas fechas suelen apuntar todas al mismo día, y ese día es el diagnóstico.

Reconstruyo la trazabilidad antes que el flujo. Si la instancia no guarda las ejecuciones correctas o lleva meses purgando, lo primero es dejar de trabajar a ciegas. Sin historial no hay diagnóstico, hay adivinanza.

Monto el flujo de errores y lo conecto a todo lo crítico. Y reviso flujo por flujo quién tiene nodos en modo continuar, porque esos son los que llevan semanas fallando sin que nadie lo sepa. Casi siempre aparece alguno.

Compruebo que existe una copia de seguridad y que se puede restaurar. Una copia que nadie ha restaurado nunca no es una copia, es una carpeta. Incluye la clave de cifrado, que es lo que la gente descubre que le falta el peor día posible.

Levanto el inventario de credenciales con fechas. Qué credencial usa qué flujo y cuándo caduca. Es la tarde peor pagada del proyecto y la que más incidencias evita durante el año siguiente.

Traducido a tu dinero, esto es lo que convierte un flujo caído en un aviso de cinco minutos en lugar de una llamada de un cliente tres semanas después. Lo caro nunca es arreglar el flujo, es el tiempo que estuvo roto sin que nadie lo supiera.

Yo soy desarrollador antes que consultor de automatización, con más de siete años construyendo producto para empresas como Kaspersky o Aave. En un rescate eso se nota en dos cosas muy aburridas. Que leo el registro en lugar de rehacer el flujo entero a ver si hay suerte, y que cuando n8n no llega escribo el código que falta. Cómo planteo un proyecto completo lo cuento en automatizaciones con n8n.

Si te quedas con una sola idea, que sea esta. Un flujo que falla con un error rojo es un problema de una tarde. Un flujo que falla en verde es un problema de tres semanas, y por eso la primera inversión no es arreglar, es enterarte.