n8n - 💡(How to fix) Fix IMAP trigger worker stuck — /deactivate returns 524, manual restart needed [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#29575Fetched 2026-05-01 05:52:29
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Timeline (top)
labeled ×3commented ×1mentioned ×1subscribed ×1

Production workflow's IMAP trigger has an orphaned/stuck worker. The public API cannot recover it: every call to /deactivate returns Cloudflare 524 (origin timeout > 120s). Disabling from the UI hangs the same way. Manual worker restart on your side appears to be the only path forward.

Workflow

  • ID: xRAmogYI3IQv6HIr
  • Name: PRODUCTION - v5.4 Routage + Distribution (SMTP)
  • Trigger: Email Trigger (IMAP), Nuxit mailbox

Timeline (UTC, 2026-04-30)

  • 08:03:54 — last successful trigger exec (id 3531)
  • 08:33:57 — Error Handler 3532 (imap_disconnect, auto_resolving)
  • 08:37:49 — Error Handler 3533 (started 37s after 3532 finished)
  • 08:41:06 — Error Handler 3534 (started 3s after 3533 finished) → pattern of residual IMAP listeners looping
  • 08:46:24 — last Error Handler activity, then silence
  • 11:00:00 — scheduled Auto-restart workflow XxEKLVK7W4TOxshG fired
  • 11:06:19 — Auto-restart's POST /workflows/xRAmogYI3IQv6HIr/deactivate failed with Cloudflare 524 after 379s (captured by Error Handler exec 3538)
  • Now — workflow still reports active: true via GET API, but produces zero trigger executions

What I tried (all failed)

  • 4x manual POST /workflows/xRAmogYI3IQv6HIr/deactivate via curl → 524 / 000 (timeouts 60–90s)
  • Disable the IMAP trigger node via partial workflow update → rejected: "No activatable trigger nodes found"
  • Standard Auto-restart cron (same endpoint, same 524)

Request

Please manually restart the worker process associated with this workflow. The public API is unreachable for state-changing ops on it.

Impact

Production mail routing for the customer has been down ~3h. No data loss expected (IMAP server retains messages until re-read), but I'd like to restore reception ASAP.

Thanks, Zak

Error Message

  • 08:33:57 — Error Handler 3532 (imap_disconnect, auto_resolving)
  • 08:37:49 — Error Handler 3533 (started 37s after 3532 finished)
  • 08:41:06 — Error Handler 3534 (started 3s after 3533 finished)
  • 08:46:24 — last Error Handler activity, then silence (captured by Error Handler exec 3538)

Root Cause

Production workflow's IMAP trigger has an orphaned/stuck worker. The public API cannot recover it: every call to /deactivate returns Cloudflare 524 (origin timeout > 120s). Disabling from the UI hangs the same way. Manual worker restart on your side appears to be the only path forward.

Workflow

  • ID: xRAmogYI3IQv6HIr
  • Name: PRODUCTION - v5.4 Routage + Distribution (SMTP)
  • Trigger: Email Trigger (IMAP), Nuxit mailbox

Timeline (UTC, 2026-04-30)

  • 08:03:54 — last successful trigger exec (id 3531)
  • 08:33:57 — Error Handler 3532 (imap_disconnect, auto_resolving)
  • 08:37:49 — Error Handler 3533 (started 37s after 3532 finished)
  • 08:41:06 — Error Handler 3534 (started 3s after 3533 finished) → pattern of residual IMAP listeners looping
  • 08:46:24 — last Error Handler activity, then silence
  • 11:00:00 — scheduled Auto-restart workflow XxEKLVK7W4TOxshG fired
  • 11:06:19 — Auto-restart's POST /workflows/xRAmogYI3IQv6HIr/deactivate failed with Cloudflare 524 after 379s (captured by Error Handler exec 3538)
  • Now — workflow still reports active: true via GET API, but produces zero trigger executions

What I tried (all failed)

  • 4x manual POST /workflows/xRAmogYI3IQv6HIr/deactivate via curl → 524 / 000 (timeouts 60–90s)
  • Disable the IMAP trigger node via partial workflow update → rejected: "No activatable trigger nodes found"
  • Standard Auto-restart cron (same endpoint, same 524)

Request

Please manually restart the worker process associated with this workflow. The public API is unreachable for state-changing ops on it.

Impact

Production mail routing for the customer has been down ~3h. No data loss expected (IMAP server retains messages until re-read), but I'd like to restore reception ASAP.

Thanks, Zak

RAW_BUFFERClick to expand / collapse

Summary

Production workflow's IMAP trigger has an orphaned/stuck worker. The public API cannot recover it: every call to /deactivate returns Cloudflare 524 (origin timeout > 120s). Disabling from the UI hangs the same way. Manual worker restart on your side appears to be the only path forward.

Workflow

  • ID: xRAmogYI3IQv6HIr
  • Name: PRODUCTION - v5.4 Routage + Distribution (SMTP)
  • Trigger: Email Trigger (IMAP), Nuxit mailbox

Timeline (UTC, 2026-04-30)

  • 08:03:54 — last successful trigger exec (id 3531)
  • 08:33:57 — Error Handler 3532 (imap_disconnect, auto_resolving)
  • 08:37:49 — Error Handler 3533 (started 37s after 3532 finished)
  • 08:41:06 — Error Handler 3534 (started 3s after 3533 finished) → pattern of residual IMAP listeners looping
  • 08:46:24 — last Error Handler activity, then silence
  • 11:00:00 — scheduled Auto-restart workflow XxEKLVK7W4TOxshG fired
  • 11:06:19 — Auto-restart's POST /workflows/xRAmogYI3IQv6HIr/deactivate failed with Cloudflare 524 after 379s (captured by Error Handler exec 3538)
  • Now — workflow still reports active: true via GET API, but produces zero trigger executions

What I tried (all failed)

  • 4x manual POST /workflows/xRAmogYI3IQv6HIr/deactivate via curl → 524 / 000 (timeouts 60–90s)
  • Disable the IMAP trigger node via partial workflow update → rejected: "No activatable trigger nodes found"
  • Standard Auto-restart cron (same endpoint, same 524)

Request

Please manually restart the worker process associated with this workflow. The public API is unreachable for state-changing ops on it.

Impact

Production mail routing for the customer has been down ~3h. No data loss expected (IMAP server retains messages until re-read), but I'd like to restore reception ASAP.

Thanks, Zak

extent analysis

TL;DR

Manually restarting the worker process associated with the stuck workflow is the most likely fix.

Guidance

  • Verify the workflow ID xRAmogYI3IQv6HIr is correctly identified and associated with the orphaned worker.
  • Check the workflow's current state using the GET API to confirm it still reports active: true.
  • Attempt to deactivate the workflow using the POST API with a longer timeout or a different approach to avoid the Cloudflare 524 timeout.
  • Consider temporarily disabling the IMAP trigger node or the entire workflow to prevent further issues until the worker can be restarted.

Notes

The issue seems to be related to a stuck worker process and the public API's inability to recover it due to timeouts. Manually restarting the worker process appears to be the only path forward, as suggested by the request.

Recommendation

Apply workaround: Manually restart the worker process associated with the stuck workflow, as the public API is unreachable for state-changing operations on it, and other attempts to deactivate or disable the workflow have failed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

n8n - 💡(How to fix) Fix IMAP trigger worker stuck — /deactivate returns 524, manual restart needed [1 comments, 2 participants]