n8n en producción: qué falla cuando el flujo crece

Un flujo de n8n que funciona en pruebas falla en producción por cuatro causas repetidas: reintentos sin idempotencia que duplican efectos, ejecuciones huérfanas que hinchan la base de datos, credenciales compartidas y sin rotar, y colas que se atascan por falta de control de concurrencia. Ninguna se arregla con más nodos: se arreglan con diseño.

Este artículo no es un tutorial de instalación. Es la lista de lo que se rompe cuando una automatización pasa de tres ejecuciones al día a tres mil, escrita desde el mantenimiento de flujos propios en producción.

¿Qué cambia entre un flujo que funciona y un flujo en producción?

Un flujo «funciona» cuando produce el resultado esperado con datos esperados y sin interferencias. Un flujo está «en producción» cuando además cumple cinco condiciones:

1. Sobrevive al fallo del entorno: la API de destino devuelve un error temporal, la red se corta, el proceso se reinicia a mitad.
2. Es reejecutable sin daño: volver a lanzarlo con la misma entrada no duplica efectos.
3. Es observable: alguien se entera de que ha fallado sin tener que abrir la interfaz.
4. Es reproducible: existe en un repositorio, no solo en la instancia.
5. Tiene límites: no puede consumir toda la capacidad ni todo el crédito de una API de terceros.

La mayoría de las automatizaciones que heredamos en auditorías cumplen la primera condición a medias y ninguna de las otras cuatro.

¿Por qué los reintentos duplican efectos?

Es el fallo más caro y el más frecuente. El escenario típico:

Un flujo recibe un evento, crea un registro en un CRM, envía un correo y actualiza una hoja de cálculo. El envío de correo devuelve un tiempo de espera agotado. El nodo reintenta. El correo, que sí se había enviado, se envía otra vez. Si además el reintento es del flujo completo, el registro del CRM se duplica.

La causa es que la operación de destino no es idempotente: ejecutarla dos veces no produce el mismo estado que ejecutarla una vez.

Correcciones, por orden de solidez:

• Clave de idempotencia. Muchas APIs aceptan una cabecera que identifica la petición para que una repetición devuelva el resultado de la primera en lugar de ejecutar de nuevo. Stripe documenta el mecanismo con precisión en su referencia sobre peticiones idempotentes. La clave debe derivarse del evento —identificador del registro más tipo de operación—, no generarse al azar en cada ejecución: si se regenera, no sirve de nada.
• Comprobar antes de escribir. Buscar por un identificador externo y crear solo si no existe. Funciona, pero deja una ventana entre la comprobación y la escritura si hay concurrencia.
• Escritura por actualización con clave natural. Usar operaciones de tipo «crear o actualizar» sobre un identificador estable en lugar de «crear».
• Registro de eventos procesados. Una tabla propia donde se anota la huella de cada evento ya tratado. Es la única defensa cuando la API de destino no ofrece nada.

Tipo de operación	¿Segura ante reintento?	Qué hacer
Lectura	Sí	Nada
Crear registro	No	Clave de idempotencia o identificador externo único
Actualizar por identificador	Normalmente sí	Vigilar contadores incrementales
Enviar correo o mensaje	No	Marcar como enviado antes de reintentar; deduplicar por destinatario y evento
Cobro o pago	No	Clave de idempotencia obligatoria
Borrado por identificador	Sí	Nada

La regla práctica: coloca el efecto irreversible lo más tarde posible en el flujo y márcalo como consumado inmediatamente después.

¿Qué son las ejecuciones huérfanas y por qué crecen?

Una ejecución huérfana es la que queda registrada como «en curso» aunque nadie la esté ejecutando: el proceso murió, el contenedor se reinició durante un despliegue o el trabajador perdió la conexión con la base de datos.

Efectos que aparecen semanas después:

• El historial de ejecuciones crece sin control y la base de datos ocupa más que todo lo demás junto.
• Las consultas de la interfaz se vuelven lentas y la instancia parece «pesada» sin causa aparente.
• Los flujos que comprueban si ya hay una ejecución en curso se bloquean para siempre, porque la ejecución fantasma nunca termina.
• Las copias de seguridad tardan cada vez más y nadie las restaura porque tardan demasiado.

Medidas:

• Política de purga del historial: conservar ejecuciones correctas pocos días y las erróneas más tiempo. Las erróneas son las que se investigan.
• Tiempo máximo de ejecución por flujo, para que nada se quede colgado indefinidamente.
• Apagado ordenado en el despliegue: dar margen a los procesos de trabajo para terminar lo que tienen entre manos antes de matarlos.
• Separar la base de datos del propio contenedor de la aplicación, y vigilar su crecimiento como una métrica más.

¿Qué falla con las credenciales?

En casi toda instalación que auditamos aparece al menos uno de estos patrones:

• Una sola credencial para todo, con permisos de administrador, usada por veinte flujos. Cuando hay que revocarla, se caen los veinte.
• Credenciales compartidas entre entornos: el flujo de pruebas escribe en el CRM de producción porque usa la misma cuenta.
• Secretos escritos dentro de nodos de código o en campos de texto, donde quedan en la exportación del flujo y en el repositorio.
• Sin rotación: tokens creados hace dos años por alguien que ya no está en la organización.
• Sin trazabilidad: la API de destino registra la acción de una cuenta genérica, así que no se puede saber qué flujo hizo qué.

Lo que hay que hacer, en orden de impacto:

1. Una credencial por integración y por entorno, con el mínimo alcance que permita el proveedor.
2. Cuentas de servicio identificables por nombre —una por flujo crítico— para que el registro del destino sea útil.
3. Rotación con calendario y responsable, no «cuando falle».
4. Secretos fuera del flujo: gestor de credenciales o variables de entorno, nunca en el cuerpo del nodo.
5. Revisión trimestral de credenciales sin uso. Toda credencial que no se ha usado en noventa días es candidata a revocación.

Esta higiene es la misma que exigimos en los sistemas que custodian datos personales; el caso concreto de un padrón de afiliados lo tratamos en CRM para asociaciones: gestionar el padrón sin exponerlo.

¿Por qué se atascan las colas?

Cuando el volumen sube, una instancia única deja de dar abasto: los flujos largos bloquean a los cortos y los webhooks empiezan a acumular retraso. La respuesta es el modo cola, donde la instancia principal recibe y encola mientras varios procesos de trabajo ejecutan en paralelo; requiere Redis y una base de datos compartida, y está documentado en la guía oficial para activar el modo cola.

Pero el modo cola no arregla por sí solo el atasco. Estas son las causas reales:

• Un flujo lento acapara los trabajadores. Un proceso que espera diez minutos a una API externa ocupa un trabajador durante diez minutos. Con cuatro trabajadores y cinco flujos así, todo lo demás espera.
• Límites de la API de destino. El destino responde con «demasiadas peticiones» y el flujo reintenta en bucle, aumentando la presión en lugar de reducirla. Hace falta espera creciente entre intentos, no reintento inmediato.
• Subflujos síncronos encadenados. Cada nivel de anidamiento multiplica la ocupación.
• Lotes gigantes. Traer cincuenta mil filas y procesarlas en memoria en una sola ejecución es una bomba de relojería. Se procesa por lotes, con punto de continuación.
• Sin límite de concurrencia. n8n permite fijar cuántas ejecuciones de producción corren a la vez y encolar el resto en orden de llegada, como describe la documentación de control de concurrencia. Sin ese límite, un pico de eventos tumba la instancia.

La separación que funciona: flujos rápidos y flujos lentos no comparten cola. El disparador recibe, valida y encola; otro flujo hace el trabajo pesado.

¿Qué pasa cuando no hay manejo de errores?

El escenario clásico: un flujo lleva tres semanas fallando y nadie lo sabe porque el fallo es silencioso. Peor todavía cuando alguien activó «continuar en caso de error» para quitarse de encima una alerta molesta: ahora el flujo termina en verde con datos vacíos y contamina los sistemas de destino.

Lo mínimo aceptable:

• Flujo de error dedicado, asociado a los flujos críticos, que recoge el fallo y avisa por un canal que alguien lee. La documentación oficial explica cómo gestionar errores con elegancia mediante el disparador de error y el nodo de detención con error.
• Fallar rápido y ruidoso en validación de entrada: si el evento no tiene los campos esperados, se detiene ahí, no tres nodos después.
• Distinguir error temporal de permanente. El temporal se reintenta con espera creciente; el permanente se manda a una cola de revisión manual y no se reintenta jamás.
• Cola de fallidos. Todo evento que no se pudo procesar debe quedar en algún sitio del que se pueda recuperar. Un error que solo existe en un log rotado es un dato perdido.

Tabla de diagnóstico rápido

Síntoma	Causa habitual	Corrección
Registros o correos duplicados	Reintento sobre operación no idempotente	Clave de idempotencia derivada del evento
La instancia va lenta sin carga aparente	Historial de ejecuciones sin purgar	Política de retención y base de datos separada
Flujos que se quedan «en curso» para siempre	Proceso muerto sin cierre	Tiempo máximo de ejecución y apagado ordenado
Fallos que nadie ve	Sin flujo de error	Flujo de error con alerta en canal vigilado
Picos que tumban la instancia	Sin límite de concurrencia	Control de concurrencia y separación de colas
Un cambio rompe tres flujos	Edición directa en producción	Repositorio, entornos separados y despliegue
No se sabe quién hizo qué en el CRM	Credencial compartida	Cuentas de servicio nominales por flujo

¿Qué observabilidad mínima hace falta?

• Tasa de fallos por flujo y por día, no solo el último error.
• Duración media y percentil alto de cada flujo: la media oculta el flujo que a veces tarda veinte minutos.
• Profundidad de la cola y número de trabajadores activos.
• Tamaño de la base de datos y crecimiento semanal.
• Alerta por ausencia de ejecuciones: un flujo que debía correr cada hora y lleva seis sin correr es tan grave como uno que falla.

Ese último punto es el que más veces salva un sistema. Los fallos ruidosos se detectan solos; los silencios, no.

¿Qué hay que versionar?

Un flujo que solo existe dentro de la instancia es un sistema sin copia y sin historia. Lo mínimo:

• Exportación de los flujos a un repositorio, con revisión de cambios.
• Entornos separados de pruebas y producción, con credenciales distintas.
• Prohibición de editar en producción sin registro de quién cambió qué.
• Documentación de una cara por flujo crítico: qué dispara, qué toca, a quién avisar si falla.

Cuando además hay agentes de IA dentro del flujo, aparece un requisito adicional: que ninguna acción irreversible se ejecute sin aprobación humana registrada. Ese patrón lo desarrollamos en Agentes de IA con supervisión humana: cómo se diseñan.

Qué hacer ahora

1. Enumera los efectos irreversibles de cada flujo y comprueba si un reintento los duplicaría. Empieza por los que tocan dinero o comunicaciones externas.
2. Fija la política de retención del historial de ejecuciones y mide el tamaño de la base de datos antes y después.
3. Inventaría credenciales: cuáles existen, quién las creó, qué alcance tienen y cuándo se rotaron por última vez.
4. Crea un flujo de error para los cinco flujos más críticos y conéctalo a un canal que alguien lea de verdad.
5. Añade la alerta por silencio en los flujos programados.

Si quieres que revisemos tu instalación y te devolvamos la lista priorizada de lo que se va a romper primero, escríbenos desde /contacto. Operamos automatizaciones propias todos los días; los fallos de esta lista los hemos pagado nosotros antes de escribirlos. El estado de nuestros controles está publicado en /trust.