Un workflow de n8n dejó de puntuar leads seis semanas sin lanzar ningún error

Un flujo montado en n8n para clasificar los leads del formulario de contacto de una clienta dejó de marcar los prioritarios durante seis semanas seguidas. No hubo ninguna ejecución fallida ni un aviso en los logs: el workflow se ejecutaba entero, devolvía JSON válido y archivaba todo como si fuera spam. La clienta se dio cuenta antes que su autor, cuando preguntó por qué un lead con pinta de tener presupuesto llevaba once días sin respuesta.

El montaje original lo hizo en una tarde. Un webhook recogía el envío del formulario, un nodo Function lo puntuaba, un nodo If ramificaba según la nota y, a partir de ahí, o saltaba un aviso por Slack y se redactaba una respuesta, o se archivaba. La lógica de puntuación eran tres líneas: si el campo budget contenía un símbolo de dólar, tres puntos; si el mensaje pasaba de 200 caracteres, uno; si no, cero.

El campo que se mudó de sitio

El problema apareció en agosto. La clienta rediseñó el formulario con un plugin de page builder, y ese plugin anidó todos los campos bajo un objeto formData en lugar de dejarlos en la raíz. El webhook seguía disparándose y el payload seguía llegando, pero body.budget pasaba a ser undefined. La comparación "".includes("$") daba false siempre y cada lead se quedaba en cero. Como no se lanzaba ninguna excepción, en n8n no aparecía nada roto.

Un workflow que se cae es ruidoso: la lista de ejecuciones se pone en rojo y, si tienes error workflows configurados, llega un aviso en segundos. Uno que termina bien pero da la respuesta equivocada no avisa, porque para la herramienta no ha pasado nada. El fallo vivía en una suposición sobre la forma de los datos de otro, que es justo lo que sobrevive a cualquier test que escribas tú mismo.

El arreglo que aplica ahora el autor es una comprobación de una línea al principio de cada función que toca payloads externos: si el campo budget no está, lanza un error. Es feo y barato, pero convierte una clasificación silenciosamente errónea en una ejecución fallida que sí aparece en los registros.

Para enterarse antes, monta un segundo workflow pequeño en un cron diario que consulta vía API el número de ejecuciones de las últimas 24 horas y avisa por Slack si cae a cero o si la puntuación media sale sospechosamente plana. Una desviación estándar sobre la nota habría cantado el fallo el primer día en vez del cuadragésimo segundo. Son unas quince líneas.

Ritmo de versiones y el coste de autoalojarlo

n8n publica a un ritmo que conviene tener presente. En los cuatro días previos al 25 de septiembre el proyecto cortó nueve versiones etiquetadas entre sus ramas estable y beta, según su página de releases. Si te autoalojas con Docker y haces pull de n8nio/n8n:latest en un cron, como recomiendan muchos tutoriales, puedes amanecer con nodos que se comportan distinto sin aviso. El autor fija ahora una etiqueta concreta y lee el changelog antes de subir.

Frente a Zapier o Make, la baza de n8n es el precio por tarea: la opción autoalojada elimina el cobro por ejecución que se vuelve caro en cuanto un flujo pasa de unos cientos de veces al mes. El autor ha movido tres automatizaciones de clientes fuera de Zapier este año solo por coste. El intercambio es que ahora te comes tú la máquina, la base de datos Postgres por detrás y la depuración cuando un nodo hace algo distinto de lo que dice la documentación. Sale a cuenta para algo que corre miles de veces al mes; no para un flujo que se usa dos veces por semana, donde la fiabilidad gestionada de Zapier justifica la cuota y el no tener un servidor que parchear.

Lo que queda es tratar una automatización entregada como un servicio en marcha y no como una función terminada. El fallo no estaba en la lógica de puntuación, sino en dar por fija la forma de unos datos que controlaba un tercero. Ese supuesto es el que se revisa primero la próxima vez.