Estoy creando un flujo de trabajo que recibe correos electrónicos entrantes (con un adjunto) usando el nodo Email Trigger (IMAP).
Cuando abro el flujo de trabajo en el editor, hago clic en Execute Workflow y envío un correo de prueba, el disparador se activa correctamente y recibo el adjunto real — todo funciona como se espera.
Sin embargo, después de Publicar el flujo de trabajo para que se ejecute en producción, los nuevos correos electrónicos entrantes no activan el flujo de trabajo en absoluto. No se crea ninguna ejecución y nada aparece en la lista de ejecuciones.
Estoy en n8n 2.0.3. Cosas que ya he descartado:
- La versión publicada es la misma que funciona en la ejecución manual (verificada en el historial de versiones).
- Envío un correo completamente nuevo, sin leer después de publicar — no uno previamente abierto/leído.
- Las credenciales de IMAP son válidas (la ejecución manual funciona cada vez).
¡Gracias de antemano por cualquier ayuda!
Por favor, comparte tu flujo de trabajo
Comparte el resultado devuelto por el último nodo
Sin resultado — el nodo disparador nunca se activa cuando se publica el flujo de trabajo, por lo que no hay ejecución para inspeccionar. En modo manual devuelve correctamente el correo y el adjunto descargado.
Información sobre tu configuración de n8n
- Versión de n8n: 2.0.3
- Base de datos (predeterminada: SQLite):
- Configuración EXECUTIONS_PROCESS de n8n (predeterminada: own, main):
- Ejecutando n8n mediante (Docker, npm, n8n cloud, aplicación de escritorio): Docker
- Sistema operativo:
No tengo experiencia con el disparador IMAP específicamente, así que no puedo hablar sobre nada relacionado con IMAP en lo que has descartado.
Una cosa básica que no veo mencionada; ¿el flujo de trabajo está marcado como Activo (no solo guardado/publicado)?
Las ejecuciones manuales de «Ejecutar flujo de trabajo» funcionan independientemente de ese toggle, pero los disparadores de producción solo se activan cuando el flujo de trabajo está realmente activo.
Yo mismo me encontré con esa distinción al principio con un tipo de disparador diferente, así que quería verificar que no fuera lo mismo aquí antes de que profundices en las causas específicas de IMAP.
Hola @TrinhNhatHuy
Analizando el JSON que proporcionaste, tu nodo Email Trigger (IMAP) no está conectado a ningún otro nodo: "connections": { "Email Trigger (IMAP)": { "main": [ [] ] } }
En n8n, hay una diferencia significativa entre “Ejecución Manual” y “Ejecución en Producción”:
- Ejecución Manual: Cuando haces clic en “Execute Workflow”, n8n ejecuta el nodo específico con el que estás interactuando y te muestra los datos que recuperó. Funciona porque esencialmente le estás pidiendo al nodo: “¿Qué encontrarías ahora mismo?”
- Ejecución en Producción: Cuando el flujo de trabajo se publica, el disparador espera un evento. Si el disparador se activa pero no está conectado a ningún nodo posterior, n8n puede no crear un registro de ejecución en el historial porque no había un “flujo de trabajo” real para procesar—el disparador se activó, pero no tenía a dónde enviar los datos.
Intenta conectar el Email Trigger a un nodo simple No-Op (Wait o Code) o a un nodo de Discord/Slack/Email y luego publícalo de nuevo.
Basándome en el punto de kjooleng (un disparador desconectado es la causa más común aquí) — si conectarlo a un nodo no lo soluciona, hay dos cosas específicas de IMAP que solo ocurren en producción, ya que «Execute» manual nunca las activa:
1. Desactiva el flujo de trabajo y luego actívalo de nuevo. El disparador IMAP solo abre su conexión de sondeo/IDLE cuando el flujo de trabajo se activa. Si esa conexión no se reestableció después de tu última publicación — o el servidor de correo interrumpió la sesión idle — el disparador permanece silencioso y no registra ejecución alguna. Desactivar y reactivar obliga a n8n a reabrirla. Esto lo soluciona más a menudo de lo que la gente espera.
2. Asegúrate de que solo una instancia principal está activa. Estás en Docker: si un segundo contenedor apunta a la misma base de datos, o estás en modo cola, los nodos de sondeo/disparador solo se ejecutan en la instancia principal — una instancia activa descarriada puede absorber silenciosamente el sondeo.
(El disparador también obtiene correo NO LEÍDO por defecto, pero ya descartaste eso enviando mensajes nuevos sin leer.)
Si sigue en silencio después de reactivar, indica si es modo de instancia única o cola y podemos reducir las posibilidades.
¡Gracias por tu apoyo! En la versión 2.0.3, ya no veo un interruptor «Activo» para el flujo de trabajo. Solo muestra la opción de publicar el flujo de trabajo, y ya lo he publicado.
thank you @kostasuser01gr , in my real workflow, i already connected it to other nodes like this
Para solucionar esto, debes indicarle a n8n cómo manejar el correo electrónico una vez que ha sido recogido.
- Abre tu nodo Email Trigger (IMAP).
- Busca el parámetro Post-process Action.
- Cámbialo de «Nothing» a una de las siguientes opciones:
- Mark as Read: Esta es la más común. El flujo de trabajo se activará en correos electrónicos «Sin leer» y, una vez activado, los marca como «Leídos» para que no se procesen nuevamente.
- Move to Folder: Mueve el correo electrónico a una carpeta «Processed». Este es el método más confiable para entornos de producción.
- Guarda y publica el flujo de trabajo nuevamente.
hola @nathan3, @kjooleng, gracias por su respuesta. Intenté tu primera sugerencia despublicando y luego publicando el flujo de trabajo nuevamente, y funcionó.
Mi preocupación es cómo puedo detectar este problema en el futuro. ¿Hay alguna forma de monitorear si el disparador IMAP ha dejado de recibir correos electrónicos, para saber cuándo el flujo de trabajo necesita ser despublicado y publicado nuevamente?
Preferiría una solución más confiable que verificar manualmente el flujo de trabajo, especialmente si la conexión IMAP puede caerse silenciosamente sin crear ningún registro de ejecución.
Puedes crear un nuevo flujo de trabajo que se ejecute en un Disparador de Programación (por ejemplo, cada 1 hora).
- Paso 1: Lee la marca de tiempo de la «Última ejecución» de tu base de datos/Google Sheet/KV Store.
- Paso 2: Usa un Nodo IF para verificar:
¿Es (Hora actual - Hora última ejecución) > 2 horas?
- Paso 3: Si es Verdadero, envíate una alerta urgente (Slack, Telegram o Correo electrónico) diciendo: «CRÍTICO: El flujo de trabajo de correo electrónico no ha procesado un correo en 2 horas. Verifica la conexión IMAP.»
Si tu proveedor de correo electrónico lo admite (por ejemplo, Gmail vía Pub/Sub), cambiar de encuestas IMAP a un Webhook basado en push es 100% más confiable porque n8n no tiene que mantener un socket abierto constante; el servidor le dice a n8n cuándo hay correo.
Para añadir algo que nadie ha mencionado todavía — junto con el watchdog de kjooleng, hay una palanca de prevención incorporada en el propio nodo.
En el nodo Email Trigger (IMAP), abre Options → Force reconnect every X minutes (predeterminado 60). Reducirlo a ~15-30 hace que n8n periódicamente cierre y reestablezca la conexión IMAP, así que un socket silenciosamente interrumpido se auto-repara sin que tengas que despublicar/republicar. Esto aborda el caso “la conexión muere silenciosamente” en la fuente, mientras que la verificación de marca de tiempo de última ejecución de kjooleng es lo que atrapa cualquier cosa que aún se cuele.
Una salvedad sobre ese watchdog de marca de tiempo: “sin email en X horas” solo equivale a “roto” si realmente esperas tráfico constante. Si el volumen de entrada es irregular, haz que el watchdog envíe un email canario al buzón en cada ciclo y verifica que fue procesado — eso prueba la conexión sin importar el correo real.
Bien saberlo, eso descarta lo que estaba pensando.
No estoy familiarizado con lo que cambió en 2.0.3 entre el antiguo botón Activo y Publicar, así que no tengo otra idea aquí.
Espero que alguien con más visibilidad sobre el cambio de 2.0.3 pueda opinar sobre si el estado publicado se asigna a otra cosa, o si esto merece su propio informe de error.
¡Hola! Este es un clásico escenario de “funciona en pruebas, falla en producción”, y es increíblemente frustrante.
Como funciona perfectamente en las pruebas manuales, tus credenciales y la configuración básica son definitivamente correctas. El problema radica en la diferencia entre cómo n8n maneja las pruebas manuales frente al polling continuo en segundo plano.
Cuando presionas “Execute Workflow”, n8n se conecta, verifica la bandeja de entrada una vez y se desconecta. Pero cuando el flujo de trabajo se publica (está activo), el disparador IMAP se ejecuta en un bucle de polling continuo en segundo plano.
Observando el JSON de tu flujo de trabajo, el principal sospechoso es la opción forceReconnect: 1. Esto le dice a n8n que fuerce una conexión completamente nueva cada vez que realiza un polling (generalmente cada 1 minuto). La mayoría de los proveedores de correo electrónico verán este ciclo rápido de conectar/desconectar desde una única dirección IP como sospechoso y aplicarán temporalmente limitaciones de velocidad o desconectarán silenciosamente las conexiones en segundo plano.
Here is the step-by-step action plan to fix this:
1. Ajusta o Elimina forceReconnect
- Abre tu nodo Email Trigger (IMAP).
- En Options, cambia
Force Reconnect de 1 a un número mucho mayor (como 10 o 20), o elimina completamente la opción si no la necesitas explícitamente.
- Guarda y reactiva el flujo de trabajo, luego envía un nuevo correo de prueba.
2. Verifica los Registros en Segundo Plano de Docker
Como el disparador nunca se activa con éxito en producción, no verás errores en la pestaña Executions de la interfaz de n8n. Los errores están ocurriendo en el proceso en segundo plano.
- Accede por SSH a tu host RHEL y ejecuta:
docker logs \ <your_n8n_container_name>
- Busca agotamientos de tiempo de conexión o bloqueos de autenticación específicamente relacionados con
emailReadImap.
3. Considera Actualizar n8n
Actualmente estás en la versión 2.0.3. Ha habido numerosas correcciones de estabilidad para polling en segundo plano y disparadores activos desde los primeros lanzamientos de 2.x. Se recomienda encarecidamente actualizar a una versión estable más nueva si ajustar el parámetro de reconexión no lo resuelve.
@TeSIdrah para responder tu pregunta: en v2.0.3, «Publish» es funcionalmente equivalente al antiguo toggle «Active» — el flujo de trabajo se ejecuta en modo de sondeo en segundo plano de la misma manera. El cambio de nombre fue puramente del lado de la interfaz, por lo que el comportamiento del trigger IMAP no debería cambiar entre versiones.
Si el trigger funciona manualmente pero no después de publicar, los culpables más probables son:
forceReconnect establecido en 1 (como señaló n8n_Sensei) — soluciona eso primero- El tiempo de espera de inactividad IMAP se está descartando silenciosamente por el servidor de correo después de que la conexión permanece abierta demasiado tiempo
Una verificación rápida: después de publicar, ve a Executions y filtra por tu flujo de trabajo. Si ves cero ejecuciones de producción para cualquier correo entrante, la conexión se está muriendo silenciosamente. Si ves ejecuciones pero generan errores, los registros te dirán qué está sucediendo.