He heredado bastantes instalaciones de n8n como para tener una opinión clara: el problema casi nunca es lo que hace el flujo, sino lo que pasa cuando algo no está donde se esperaba. Un campo vacío, una credencial caducada, un cliente que ya existía. El flujo no avisa, no reintenta y nadie se entera hasta que un cliente pregunta.

Estos cinco flujos son los que monto una y otra vez. No son complicados; lo que los hace duraderos es lo que llevan alrededor.

Tres reglas antes de tocar un nodo

Las tres las he aprendido arreglando flujos ajenos, que es la mejor escuela y la más cara.

  1. Un flujo, una responsabilidad. Si tienes que explicarlo con la palabra «y» dos veces, son dos flujos.
  2. Todo lo que entra se guarda tal cual antes de transformarlo. El original en una tabla, con su fecha.
  3. Todo error tiene destinatario. Un canal donde alguien mira; si no hay destinatario, el error no existe.

La primera regla es la que más se incumple. El nodo que recibe el formulario, valida, escribe en el CRM, manda el correo y actualiza la hoja parece eficiente hasta el día que el CRM devuelve un 429: entonces no sabes si el correo salió, si la hoja se actualizó y si puedes reintentar sin duplicar nada.

«Un flujo que hace cinco cosas no falla cinco veces menos: falla en cinco sitios y en ninguno del todo.»

Los cinco flujos

Flujo 1 · Entrada de datos

Un webhook recibe formularios, correos o altas. Hace tres cosas y ninguna más: guarda la carga original en una tabla, valida los campos mínimos y encola el resto del trabajo. Si la validación falla, escribe el motivo en la misma fila y termina bien: un dato malo no es un error del sistema, es un dato malo, y conviene distinguirlo.

Flujo 2 · Informe periódico

Se dispara por calendario, recoge datos de dos o tres fuentes, compone y envía. La clave está en la idempotencia: si lo lanzas dos veces el día 1, debe producir un solo informe. Un campo con el periodo ya generado en la tabla y una comprobación al principio resuelven el 90 % de los sustos.

Flujo 3 · Sincronización entre dos sistemas

El más peligroso. Regla que no negocio: la sincronización va en una sola dirección y hay un sistema que manda. Las bidireccionales acaban en bucles y en registros duplicados con dos verdades. Cuando el cliente insiste en que sea en los dos sentidos, monto dos flujos unidireccionales con campos distintos y un identificador compartido.

Flujo 4 · Avisos

Notificar es fácil; notificar sin agotar la paciencia de nadie, no. Tres decisiones: a quién, con qué umbral y con qué agrupación. Un aviso por evento en un canal compartido se ignora en dos semanas. Un resumen a las nueve y las urgencias en el momento sobrevive.

Flujo 5 · El vigilante

El que casi nadie monta. Cada noche revisa las ejecuciones de los otros cuatro: cuántas hubo, cuántas fallaron, si alguno no se ejecutó ninguna vez —el fallo más silencioso de todos— y si alguna credencial caduca en menos de quince días. Manda un mensaje corto incluso cuando todo va bien, para que su silencio también sea información.

DETALLE QUE SALVA VIERNES >Que el vigilante avise también cuando no hay nada que avisar. Si el canal lleva tres días callado, o todo va perfecto o el vigilante está caído — y sin el mensaje diario no sabes cuál de las dos.

Reintentos y errores sin drama

n8n permite reintentos por nodo; el problema es decidir qué merece reintento. Los errores de red y los límites de tasa, sí: tres intentos con espera creciente. Un dato inválido, no: reintentarlo mil veces no lo mejora, sólo llena el registro.

TIPO DE FALLO

QUÉ HACER

Tiempo de espera agotado, 5xx

3 reintentos con espera 1 · 5 · 25 s

Límite de tasa (429)

Reintento con la espera que indique la cabecera

Credencial caducada

Cero reintentos, aviso inmediato con el nombre de la credencial

Dato inválido

Cero reintentos, fila marcada y fin correcto

Error desconocido

Un reintento, y si vuelve a fallar, aviso con el identificador de ejecución

Y un flujo de error global, que en n8n se configura una vez y se aplica a todos: captura lo que ninguna rama previó, guarda el identificador de la ejecución y manda el enlace directo. Poder abrir la ejecución exacta que falló convierte una tarde de investigación en dos minutos.

Cuando la API cambia

Cambiará. En un año he visto tres cambios de campo que rompieron flujos ajenos sin avisar. Lo que reduce el daño es no depender de la forma exacta de la respuesta: extraer los cuatro o cinco campos que usas en un nodo propio al principio, y que el resto del flujo trabaje con tus nombres, no con los del proveedor.

Cuesta un nodo más y ahorra la diferencia entre cambiar una línea y revisar catorce nodos buscando dónde se llamaba aquello.

  • Un nodo de normalización al principio de cada flujo con datos externos.
  • Nombres de campo propios y estables, documentados en dos líneas dentro del flujo.
  • Nada de credenciales pegadas en nodos sueltos: siempre desde el gestor de credenciales.
  • Exportación del flujo en JSON guardada en el repositorio del cliente, no sólo en la instancia.

Qué cuesta mantener esto

Cinco flujos bien montados me piden entre una y dos horas al mes de atención: revisar el mensaje del vigilante, renovar alguna credencial y corregir un caso nuevo cada seis o siete semanas. La instancia, si es autoalojada, entre diez y veinte euros al mes.

Ese es el número que conviene decir en voz alta al presupuestar. Un montaje sin mantenimiento acordado es un flujo que dentro de nueve meses estará apagado y nadie sabrá desde cuándo.