IMAP not triggering

Describe the problem/error/question

When I add an IMAP node to check a subfolder, the new mails are marked as read, due to the config, but the node has not triggered. When I “unread” them and trigger the node manually, it works. Just automatic trigger is not working correctly

Please share your workflow

Information on your n8n setup

  • 1.94.0
  • Database: SQLite
  • EXECUTIONS_PROCESS: not set explicitly
  • **Running n8n via Docker
  • Operating system: Debian 11.3

IMAP Email Trigger Operation
The node connects to the IMAP server and uses the IDLE command (if available) to listen for new messages in real time.

If IDLE is not supported, you can use periodic polling.

Each new message that matches the filters triggers the flow.

Try the following:

Make sure you use the correct folder name, as interpreted by the IMAP server.

Example: Gmail: “[Gmail]/Inbox” or “INBOX/Subfolder”

Prevent other clients (such as Outlook) from automatically marking emails as read

As mentioned, mails are marked read by the node, it just does not trigger when enabled. It triggers only when running manually. Hence I assume filters and folder name are correct.
There is no other client marking the mails read.
The IMAP server is Fastmail.

Same Problem here. IMAP Trigger ist working correct in Test Mode, in active Mode Mails get marked as Read but nothings happens in the Workflow.

I have the same issue. I use n8n Version 1.88.0 (self hosted). IMAP from fastmail.
For gmail IMAP it worked fine.

Any solution found for this one? I am facing the exact same issue. Only Gmail IMAP Sseems working properly

Delete and recreate the workflow, I just tried and it works

I encountered a very strange problem. The email trigger of the archived workflow was still triggered.

Hey there,

I also have issues with the IMAP trigger on n8n stable @ docker. In manual test it sort of randomly succeeds, than again listening forever without input when adding new mails to the source folder and also not working when activated … :frowning:

I’m facing the same issue now. In addition, my workflow is running when I’m clicking on ‘Execute workflow’ but it’s neither getting published nor unpublished.

You can unarchive a workflow by following these steps. Go to workflows. On top right, you see ‘filter’ icon (beside ‘search’ and ‘create folder’ icons). Click on it. You will see a check box with label ‘Show archived workflows’. Check the box and you’ll see archived workflows. open the corresponding workflow, unarchive it (just like you archived it). stop the trigger and delete it if you wish to.

Same problem using the payed version of n8n on the cloud. I’m using IMAP of a Hostinger Mail Server.

From my tests, it seems the parameter Format=Resolved works, but Format=Simple don’t

I’m using self hosted version with Hostinger and it isn’t working for me too. When I add credentials it shows “Connection tested successfully” but node is not triggering. I’ve tested it with “INBOX” and “INBOX.subfolder”, Custom Email Rules both [“UNSEEN”] and [“ALL”]

And it seems that the Customer **(Un)**Success department is not very interested in fixing the IMAP problem, or even showing up here to provide any update or feedback.

Hallo zusammen,

Danke, dass ihr das gemeldet habt — wir haben mehrere Fehler im IMAP Email Trigger Node identifiziert und behoben, die dieses Verhalten verursachen könnten.

Was ist passiert: Wenn der IMAP-Server bestimmte E-Mail-Formate zurückgab, konnte der Trigger stillschweigend abstürzen und den Workflow im Hintergrund deaktivieren. E-Mails würden trotzdem als gelesen markiert (da dies vor dem Absturz passierte), aber der Workflow würde sich nie ausführen. Dies betraf besonders das Simple-Format — ein Wechsel zu Resolved konnte das Problem umgehen, wie einige von euch entdeckt hatten.

Was wir behoben haben:

  • Eine Sicherheitsprüfung für fehlerhaft formatierte E-Mail-Header im Simple-Format hinzugefügt — zuvor würde ein fehlender Header den Trigger zum Absturz bringen und den Workflow stillschweigend deaktivieren

  • Die Mark-as-Read-Logik behoben, um nur E-Mails zu kennzeichnen, die tatsächlich verarbeitet und an den Workflow übermittelt wurden

  • Doppelte Verarbeitung beim Empfang großer E-Mail-Batches (20+) behoben

  • Concurrency-Schutz gegen schnelle E-Mail-Benachrichtigungen hinzugefügt

Workaround bis zum Fix verfügbar ist: Falls ihr dieses Problem immer noch habt, versucht, den Format-Parameter zu Resolved zu wechseln. Stellt auch sicher, dass die Option Force Reconnect Every Minutes aktiviert ist (unter Options) — dies hilft bei IMAP-Servern, die Benachrichtigungen über neue E-Mails nicht zuverlässig senden.

Der Fix befindet sich in PR #30375 und sollte bald live gehen. Danke für die detaillierten Berichte!

Schön zu sehen, dass sich das n8n-Team damit auseinandersetzt! Danke an @garrit für die ausführliche Erklärung, was tatsächlich passiert ist, und für die Lösung in PR #30375.

Hier ist eine kurze Zusammenfassung der wichtigsten Punkte für alle, die auf diesen Thread stoßen:

Grundursache: Wenn der IMAP-Server bestimmte fehlerhafte E-Mail-Header zurückgab, stürzte der Trigger stillschweigend ab und deaktivierte den Workflow im Hintergrund. E-Mails wurden weiterhin als gelesen markiert, aber nichts wurde ausgeführt.

Workaround (bis zum Versand der Lösung):

  • Wechseln Sie den Format-Parameter zu Resolved statt Simple
  • Aktivieren Sie Force Reconnect Every Minutes unter Options

Permanente Lösung: Enthalten in PR #30375. Beachten Sie die Changelog-Einträge für die Version, in der sie implementiert wird, und aktualisieren Sie, sobald sie verfügbar ist.

Großartig, wie die Community hier hartnäckig daran gearbeitet hat, dass das gründlich untersucht wurde!

Das funktioniert. Ich habe mit diesem Problem seit mehreren Stunden gekämpft. Als ich das Format auf „Gelöst