I’m building a workflow that receives incoming emails (with an attachment) using the Email Trigger (IMAP) node.
When I open the workflow in the editor, click Execute Workflow, and send a test email, the trigger fires correctly and I receive the actual attachment — everything works as expected.
However, after I Publish the workflow so it runs in production, new incoming emails do not trigger the workflow at all. No execution is created and nothing shows up in the executions list.
I’m on n8n 2.0.3. Things I’ve already ruled out:
- The published version is the same one that works in manual execution (verified in version history).
- I send a brand-new, unread email after publishing — not a previously opened/read one.
- The IMAP credentials are valid (manual execution works every single time).
Thanks in advance for any help!
Please share your workflow
Share the output returned by the last node
No output — the trigger node never fires when the workflow is published, so there is no execution to inspect. In manual mode it returns the email and the downloaded attachment correctly.
Information on your n8n setup
- n8n version: 2.0.3
- Database (default: SQLite):
- n8n EXECUTIONS_PROCESS setting (default: own, main):
- Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
- Operating system:
I don’t have experience with the IMAP trigger specifically, so I can’t speak to anything IMAP-related in what you’ve ruled out.
One basic thing I don’t see mentioned though; is the workflow toggled Active (not just saved/published)?
Manual “Execute Workflow” runs regardless of that toggle, but production triggers only fire when the workflow is actually active.
I ran into that distinction myself early on with a different trigger type, so wanted to check it wasn’t the same thing here before you dig further into IMAP-specific causes.
Hi @TrinhNhatHuy
Looking at the JSON you provided, your Email Trigger (IMAP) node is not connected to any other nodes: "connections": { "Email Trigger (IMAP)": { "main": [ [] ] } }
In n8n, there is a significant difference between “Manual Execution” and “Production Execution”:
- Manual Execution: When you click “Execute Workflow,” n8n runs the specific node you are interacting with and shows you the data it retrieved. It works because you are essentially asking the node, “What would you find right now?”
- Production Execution: When the workflow is published, the trigger waits for an event. If the trigger fires but is not connected to any subsequent nodes, n8n may not create an execution record in the history because there was no “workflow” to actually process—the trigger fired, but had nowhere to send the data.
Try connecting the Email Trigger to a simple No-Op (Wait or Code node) or a Discord/Slack/Email node and then publish it again.
Building on kjooleng’s point (a disconnected trigger is the most common cause here) — if wiring it to a node doesn’t fix it, two IMAP-specific things that only bite in production, since manual “Execute” never hits them:
1. Toggle the workflow Active off, then on again. The IMAP trigger only opens its polling/IDLE connection when the workflow is activated. If that connection wasn’t re-established after your last publish — or the mail server dropped the idle session — the trigger sits silent and logs no execution at all. Deactivating and reactivating forces n8n to reopen it. This fixes it more often than people expect.
2. Make sure only one main instance is active. You’re on Docker: if a second container points at the same DB, or you’re in queue mode, polling/trigger nodes only run on the main instance — a stray active instance can quietly swallow the polling.
(The trigger also fetches UNSEEN mail by default, but you already ruled that out by sending fresh unread messages.)
If it’s still silent after reactivating, say whether it’s single-instance or queue mode and we can narrow it down.
Thank you for your support! In version 2.0.3, I no longer see an “Active” toggle for the workflow. It only shows the option to publish the workflow, and I have already published it.
thank you @kostasuser01gr , in my real workflow, i already connected it to other nodes like this
To fix this, you must tell n8n how to handle the email once it has been picked up.
- Open your Email Trigger (IMAP) node.
- Look for the Post-process Action parameter.
- Change it from “Nothing” to one of the following:
- Mark as Read: This is the most common. The workflow will trigger on “Unread” emails, and once triggered, it marks them as “Read” so they aren’t processed again.
- Move to Folder: Move the email to a “Processed” folder. This is the most reliable method for production environments.
- Save and Publish the workflow again.
hi @nathan3, @kjooleng, thank you for your response. I tried your first suggestion by unpublishing and then publishing the workflow again, and it worked.
My concern is how I can detect this issue in the future. Is there any way to monitor whether the IMAP trigger has stopped receiving emails, so I know when the workflow needs to be unpublished and published again?
I would prefer a more reliable solution than manually checking the workflow, especially if the IMAP connection can be dropped silently without creating any execution logs.
You can create a new workflow that runs on a Schedule Trigger (e.g., every 1 hour).
- Step 1: Read the “Last Run” timestamp from your database/Google Sheet/KV Store.
- Step 2: Use an IF Node to check:
Is (Current Time - Last Run Time) > 2 hours?
- Step 3: If True, send yourself an urgent alert (Slack, Telegram, or Email) saying: “CRITICAL: Email Workflow has not processed an email in 2 hours. Check IMAP connection.”
If your email provider supports it (e.g., Gmail via Pub/Sub), switching from IMAP polling to a Webhook-based push is 100% more reliable because n8n doesn’t have to maintain a constant open socket; the server tells n8n when there is mail.
To add one thing nobody’s mentioned yet — alongside kjooleng’s watchdog, there’s a built-in prevention lever on the node itself.
On the Email Trigger (IMAP) node, open Options → Force reconnect every X minutes (default 60). Lowering it to ~15-30 makes n8n periodically tear down and re-establish the IMAP connection, so a silently dropped socket self-heals without you having to unpublish/republish. That tackles the “connection dies quietly” case at the source, while kjooleng’s last-run-timestamp check is what catches anything that still slips through.
One caveat on that timestamp watchdog: “no email in X hours” only equals “broken” if you actually expect steady traffic. If inbound volume is irregular, have the watchdog send a canary email to the mailbox each cycle and verify it got processed — that tests the connection regardless of real mail.
Good to know, that rules out what I was thinking.
I’m not familiar with what changed in 2.0.3 between the old Active toggle and Publish, so I don’t have a next guess here.
Hopefully someone with more visibility into the 2.0.3 change can weigh in on whether the published state maps to something else, or if this is worth its own bug report.
Hey there! This is a classic “works in test, fails in prod” scenario, and it’s incredibly frustrating.
Because it works perfectly when testing manually, your credentials and basic setup are definitely correct. The issue lies in the difference between how n8n handles manual testing vs. active background polling.
When you hit “Execute Workflow”, n8n connects, checks the inbox once, and disconnects. But when the workflow is published (active), the IMAP trigger runs in a continuous background polling loop.
Looking at your workflow JSON, the primary suspect is the forceReconnect: 1 option. This tells n8n to force a completely new connection every single time it polls (usually every 1 minute). Most email providers will view this rapid connect/disconnect cycle from a single IP as suspicious and temporarily rate-limit or silently drop the background connections.
Here is the step-by-step action plan to fix this:
1. Adjust or Remove forceReconnect
- Open your Email Trigger (IMAP) node.
- Under Options, change
Force Reconnect from 1 to a much higher number (like 10 or 20), or completely remove the option if you don’t explicitly need it.
- Save and re-activate the workflow, then send a new test email.
2. Check the Docker Background Logs
Since the trigger never successfully fires in production, you won’t see any errors in the n8n UI Executions tab. The errors are happening in the background process.
- SSH into your RHEL host and run:
docker logs <your_n8n_container_name>
- Look for connection timeouts or authentication blocks specifically related to
emailReadImap.
3. Consider Updating n8n
You are currently on version 2.0.3. There have been numerous stability fixes to background polling and active triggers since the early 2.x releases. Upgrading to a newer stable version is highly recommended if adjusting the reconnect parameter doesn’t resolve it.
@TeSIdrah to answer your question: in v2.0.3, “Publish” is functionally equivalent to the old “Active” toggle — the workflow runs in background polling mode just the same. The rename was purely UI-side, so the IMAP trigger behavior isn’t supposed to change between versions.
If the trigger works manually but not after publishing, the most likely culprits are:
forceReconnect set to 1 (as n8n_Sensei pointed out) — fix that first- IMAP idle timeout being dropped silently by the mail server after the connection stays open too long
A quick check: after publishing, go to Executions and filter by your workflow. If you see zero production executions for any incoming email, the connection is dying silently. If you see executions but they error out, the logs will tell you what’s happening.
Check the production execution log and confirm the published workflow is active on the same instance that holds the IMAP credential. I would also test with a fresh unread message after publish since manual execution can use a different trigger path.