Los 15 Errores Más Comunes al Usar n8n (y Cómo Evitarlos)

Voy a ser honesto: cuando empecé con n8n, cometí todos los errores que vas a leer acá. Cada uno de ellos. Algunos me costaron horas de frustración, otros me costaron datos perdidos, y uno particularmente doloroso me costó un cliente que recibió 347 emails duplicados a las 3 de la mañana.

Llevo más de dos años usando n8n diariamente para automatizar procesos en startups que asesoro desde Trinico Ventures, y en ese tiempo aprendí (a los golpes) qué funciona y qué no. Esta lista es el resultado de esas lecciones, y ojalá te ahorre el dolor de aprenderlas por tu cuenta.

Si recién estás arrancando con n8n, podés crear tu cuenta acá y seguir esta guía mientras explorás la plataforma.

Error 1: No activar el workflow después de crearlo

Este es el error número uno de todo principiante y es tan básico que da vergüenza admitirlo. Pero ahí vamos: yo pasé una tarde entera creando un workflow perfecto para recibir webhooks de un formulario, lo probé con el botón de “Test Workflow”, funcionó impecable, y me fui feliz. Al día siguiente, el cliente me pregunta por qué no le llegaron los datos del formulario.

El problema: nunca activé el workflow. El toggle de activación está en la esquina superior derecha del editor, y si no lo encendés, el workflow solo funciona cuando lo ejecutás manualmente o con el botón de test. Los triggers (webhooks, cron, etc.) no se activan hasta que prendés ese toggle.

Cómo evitarlo: Hacé de la activación el último paso de tu proceso. Después de probar, siempre verificá que el toggle esté en verde. Un tip extra: la URL del webhook cambia entre el modo de prueba y el modo de producción. Cuando activás el workflow, usá la URL de producción (la que dice “webhook” sin “webhook-test”).

Error 2: No manejar errores en los nodos

Cuando estás aprendiendo, todos tus workflows son caminos felices: asumís que la API siempre va a responder, que los datos siempre van a tener el formato correcto, que el email siempre se va a enviar. En producción, nada de eso es cierto.

Yo tenía un workflow que consultaba una API externa, procesaba los datos y los guardaba en una base de datos. Un día la API empezó a devolver errores 503 intermitentes. Como no tenía manejo de errores, el workflow fallaba silenciosamente y yo no me enteraba hasta que el cliente me preguntaba por qué no había datos nuevos.

Cómo evitarlo: En cada nodo que hace una llamada externa (HTTP Request, nodos de servicios, bases de datos), andá a Settings y configurá la opción “On Error”. Tenés tres opciones: “Stop Workflow” (para todo), “Continue” (ignora el error y sigue), y “Continue Using Error Output” (la mejor opción, porque te permite manejar el error con un flujo alternativo).

Creá siempre un flujo de error que notifique: un nodo de Slack, email o lo que sea que te avise cuando algo falla. Los 5 minutos que tardás en configurar esto te van a ahorrar horas de debugging después.

Error 3: Hardcodear credenciales en los nodos

Al principio, cuando necesitaba un API key, la ponía directamente en el campo del nodo HTTP Request. “Total, funciona igual”, pensaba. Hasta que un día compartí un workflow exportado con un colega y me di cuenta de que las credenciales estaban en el JSON exportado, visibles para cualquiera.

Cómo evitarlo: Siempre usá el sistema de credenciales de n8n (Settings, luego Credentials). Las credenciales se almacenan encriptadas y no se exportan cuando compartís un workflow. Además, si necesitás cambiar una API key, la cambiás en un solo lugar en vez de buscar en todos los nodos donde la usaste.

Para valores que cambian entre ambientes (como URLs base, IDs de proyecto, etc.), usá variables de entorno en lugar de hardcodearlos en los nodos.

Error 4: No usar el nodo IF para validar datos

Este error es el responsable de los 347 emails duplicados que mencioné al principio. Tenía un workflow que procesaba registros de una base de datos y enviaba emails. El problema: no validaba si el campo de email estaba vacío o si era un email válido. Resultado: el workflow intentó enviar emails a campos vacíos, a strings que no eran emails, y a registros duplicados. El servicio de email no se quejó por los vacíos (simplemente falló silenciosamente), pero los duplicados sí se enviaron.

Cómo evitarlo: Antes de cualquier acción importante (enviar email, crear registro, llamar API), poné un nodo IF que valide los datos. Como mínimo, verificá que los campos requeridos no estén vacíos, que los emails tengan formato válido (un contains con “@” y “.” es suficiente para una validación básica), que los números sean realmente números, y que no estés procesando duplicados.

Un patrón que uso mucho es poner un nodo “Remove Duplicates” (usando el nodo Code con un `Set` que filtra por un campo único) antes de procesar listas grandes.

Error 5: Crear workflows gigantes en lugar de modulares

Mi primer workflow “serio” tenía 47 nodos. Hacía de todo: recibía datos de un webhook, los validaba, los guardaba en tres bases de datos distintas, enviaba emails, publicaba en Slack, generaba un PDF y actualizaba un Google Sheet. Era un monstruo imposible de mantener.

Cada vez que algo fallaba, tardaba 20 minutos en encontrar cuál de los 47 nodos era el problema. Y modificar algo era un riesgo porque cualquier cambio podía romper otra parte del flujo.

Cómo evitarlo: Dividí los workflows grandes en workflows más pequeños y especializados. n8n tiene un nodo llamado “Execute Workflow” que permite llamar a un workflow desde otro, como si fuera una función.

Mi regla personal: si un workflow tiene más de 15 nodos, probablemente debería ser dos o tres workflows separados. Por ejemplo, en vez de un mega-workflow, tengo: un workflow de recepción y validación de datos, un workflow de persistencia (guardar en bases de datos), un workflow de notificaciones, y un workflow de generación de documentos. Cada uno se puede probar, debuggear y modificar de forma independiente.

Error 6: No entender la diferencia entre ejecución manual y por trigger

Este error me hizo perder un par de horas la primera vez. Cuando probás un workflow manualmente (con el botón “Execute Workflow”), los datos de prueba son diferentes a los datos reales que llegan por un trigger.

Por ejemplo, si tu trigger es un webhook, cuando probás manualmente no hay datos de webhook. n8n te va a mostrar datos de ejemplo o datos vacíos. Esto puede hacer que tu workflow parezca que funciona en la prueba pero falle en producción, o viceversa.

Cómo evitarlo: Usá el botón “Test Workflow” en lugar de “Execute Workflow” cuando sea posible. “Test Workflow” espera a que llegue un evento real al trigger y lo procesa. Para webhooks, esto significa que tenés que enviar una petición real al webhook de prueba mientras n8n está esperando.

Otro tip: el nodo Manual Trigger es útil durante el desarrollo. Podés poner un Manual Trigger temporalmente, conectarle un nodo Set con datos de prueba que simulen lo que llegaría por el trigger real, y así probar el resto del workflow sin depender del evento externo. Cuando terminés, reemplazalo por el trigger real.

Error 7: Ignorar los límites de las APIs externas

Las APIs tienen límites de solicitudes (rate limits) y si los superás, empiezan a devolver errores 429 (Too Many Requests). Cuando estaba empezando, no tenía idea de esto y mis workflows que procesaban listas grandes fallaban misteriosamente a la mitad.

Cómo evitarlo: Antes de integrar una API, leé su documentación de rate limits. Después, configurá tu workflow para respetar esos límites:

Usá el nodo SplitInBatches para procesar items en grupos en lugar de todos de una vez. Agregá nodos Wait entre batches para darle tiempo a la API de recuperarse. En el nodo HTTP Request, configurá los reintentos (Settings, luego Retry on Fail) con un intervalo que aumente con cada intento.

Como regla general, si estás procesando más de 50 items contra una API externa, siempre usá batches con wait.

Error 8: No configurar la zona horaria

Los Schedule Triggers y los nodos Wait dependen de la zona horaria configurada en n8n. Si no configurás la zona horaria correcta, tus workflows programados van a ejecutarse a horas equivocadas.

Yo configuré un workflow para enviar un reporte diario a las 9 de la mañana. El primer día lo recibí a las 5 de la mañana porque n8n estaba usando UTC en lugar de la hora de Chile (UTC-4).

Cómo evitarlo: En n8n self-hosted, configurá la variable de entorno `GENERIC_TIMEZONE` con tu zona horaria IANA. Para Chile es `America/Santiago`, para Argentina es `America/Argentina/Buenos_Aires`, para México es `America/Mexico_City`, para Colombia es `America/Bogota`.

En n8n Cloud, podés configurar la zona horaria en Settings, luego General. Verificá que esté correcta antes de crear workflows con Schedule Triggers.

Error 9: Usar SQLite en producción

n8n viene con SQLite como base de datos por defecto. Para probar y desarrollar, funciona bien. Para producción, es una receta para el desastre.

SQLite no maneja bien las escrituras concurrentes. Si tenés varios workflows ejecutándose simultáneamente (lo cual es muy común en producción), las escrituras a la base de datos se van a bloquear entre sí y eventualmente vas a perder datos de ejecuciones o, peor, la base de datos se va a corromper.

Cómo evitarlo: Usá PostgreSQL. La configuración es simple: agregá un contenedor de PostgreSQL a tu Docker Compose (o usá un servicio de PostgreSQL managed como el que ofrece DigitalOcean o Supabase) y configurá las variables de entorno `DB_TYPE=postgresdb` junto con los datos de conexión.

La migración de SQLite a PostgreSQL se puede hacer exportando los workflows como JSON e importándolos en la nueva instancia. Las credenciale