n8n self-hostedのQueue modeで実行がQueuedのまま進まないとき、workerとRedisを切り分ける

n8nのQueue modeで実行がQueuedのまま進まないときは、mainの画面が開くことと、workerが仕事を取り出せることを分けて確認します。受付側が生きていても、workerが起動していない、違うRedisへ接続している、databaseへ届かない、といった境界で実行は止まります。

この記事はSelf-hostedの運用担当者向けに、受付・queue・worker・保存先を一件のexecutionで対応させる診断手順です。queueの削除や再投入を最初の対処にはせず、既に外部処理が行われていないかを確認します。

どの境界まで進んだかを分ける

公式のQueue mode資料では、mainがexecutionを生成し、Redis経由でIDを渡し、workerがdatabaseから必要な情報を取得して実行する流れを説明しています。workerはRedisとn8n databaseの両方へ接続する必要があります。n8n：Enable queue mode（新しいタブで開く）

表は横にスクロールできます

地点	確認する証拠	その先で疑う範囲
受付	発生時刻とexecution ID	queueへ渡るまでの経路
workerによる取得	同じIDの開始記録	worker接続・空き・実行開始
node実行	最初に実行したnodeとエラー	credential・入力・接続先
完了・保存	worker結果と一覧の状態	database保存・表示の確認

ログに出るqueue jobのIDと、n8nのexecution IDも混同しないでください。両方が分かる場合は対応を控え、一方だけの数字を別のログで探して「実行されていない」と判断しないようにします。

mainとworkerの設定を並べる

設定ファイルのつもりの値ではなく、現在稼働している各processの構成を確認します。container名やPod名があるだけでは、workerとして起動している証明にはなりません。起動役割、n8nの版、実行mode、接続対象を、秘密値を出さずに記録します。

表は横にスクロールできます

項目	照合すること
起動役割	mainとworkerを想定どおり分けているか
実行mode	Queue modeの構成が各対象へ適用されているか
Redis	接続先、port、database番号等の対象が一致するか
n8n database	workerとmainが同じ対象データを参照するか
稼働状態	再起動・接続断・容量不足等が続いていないか

Redisのpassword、databaseのcredential、暗号鍵を比較表へ貼る必要はありません。秘密の管理場所と適用対象を担当者が確認し、診断共有には接続先を区別できる最小情報だけを残します。接続できない原因を解消するために、認証を無効化したり、portを外部公開したりする対応には進まないでください。

公式資料にはRedisの接続設定やworker構成が掲載されていますが、そのサンプルを運用環境へ丸ごと上書きしません。実際のnetwork、TLS、認証、データ保存先に合わせて、差のある項目だけを確認します。

起動していることと、実行できることを分ける

利用環境に既にhealth checkが設定されているなら、worker自体の生存確認と、database・Redisへのreadinessを別に見ます。現行公式資料は、worker用のhealth checkを有効化した場合の生存／readiness endpointを説明しています。ただし、そこで正常でも対象workflowが完了する保証にはなりません。

health checkがない環境で、診断のために外部公開を追加する必要はありません。権限のある運用担当者が、起動ログと接続ログを同じ時刻帯で確認します。mainだけのログを見て、worker側の接続を確認したことにしないでください。

表は横にスクロールできます

観察	次に見ること
workerが起動・終了を繰り返す	最初の起動エラー、適用設定、resource不足
Redisの接続断が繰り返される	worker側からの到達性、接続先、TLS・認証
workerが開始するがすぐ失敗する	databaseアクセス、credential復号、最初のnode
特定workflowだけ進まない	取得後の入力・node・外部サービス
一部workerだけ失敗する	そのprocessの版・設定・接続先との差

ここで示す分類は原因の候補です。接続断のログがあっただけで、すべてのQueuedをRedisだけの問題と決めつけません。対象IDがどこまで到達したかと、その時刻のエラーを組にして判定します。

workerを増やす前に、待ちと停止を区別する

全workerが処理中で、既存executionが完了するたびに次が開始されるなら、まず処理量と処理時間を確認します。一方、仕事があってもworkerが一件も取得しないなら、台数を増やす前に接続・構成を調べます。

並列度を上げると、database接続数や外部APIへの要求も増える可能性があります。main・worker・databaseのどこが不足しているか分からないまま、timeoutや接続上限をまとめて変更すると、原因の比較ができなくなります。変更は一項目ずつ記録し、処理開始と完了の両方を確認します。

workerがnodeを実行した後で止まった場合は、すでに通知・更新等が行われているかもしれません。「Queuedに見えるから未処理」と扱わず、外部側のevent IDや処理済み状態も確認してください。

queueを消す前に保全する

Redisのflush、execution削除、同じ入力の大量再送は、調査の最初に行う操作ではありません。必要なexecution ID、時刻、起動・取得ログ、設定変更履歴を確保し、処理済みと未処理を分けます。再起動が必要な場合も、実行中の仕事と停止方法、再開後の二重処理を運用担当者が確認します。

ログを増やす場合は、payload・token・credentialが含まれる範囲と保存先を先に決めます。全文を公開の質問へ貼らず、秘密を除いた対象ID、role、時刻、最初のエラーを共有します。保存する実行データの種類と量は、workflowとインスタンスの保存設定でも確認します。n8n：Manage execution data（新しいタブで開く）

合格条件は一件の受付から完了まで追えること

機密や副作用のない確認用workflowを用意できる環境で、一件の受付、worker開始、node処理、結果保存を対応させます。その後、想定する複数件でも欠落・重複・待ち時間を確認します。空いているworkerの表示だけで復旧済みとはしません。

未解決なら、main／workerの版と役割、対象execution、Redis・databaseの接続対象、取得の有無、最初のエラーを整理して管理者へ渡します。本文は公式構成に基づく診断手順で、特定のn8nインスタンスのqueue検査、再起動、再投入や負荷試験を実施した報告ではありません。