「n8n Execution limit reached」が出たら最初に見る4ステップと、課金か構成見直しかの判断軸

公開: 2026年6月16日更新: 2026年8月29日約16分で読めます

「n8n Execution limit reached」が出たら最初に見る4ステップと、課金か構成見直しかの判断軸

ある朝、Slackに「昨日まで動いていた自動化が、全部止まっています」という連絡が来る。直前に新しいノードを追加していたから、誰もが「あの変更のせいだ」と思っている。

ところが、開いたエラーログにはこう書いてあった。Execution limit reached. Consider upgrading your plan.。コードは無関係でした。n8n Cloud の月次実行回数が、契約プランの上限に達していただけです。

この記事は2部構成になっています。前半は、n8n が止まったときに最短で原因にたどり着く4ステップ。とくに「n8n Execution limit reached」というエラーの正体を切り分けます。後半は、このエラーに繰り返し当たるようになったとき、上位プランに課金して上限を上げるか、重い処理を別の構成に逃がすか、その判断軸です。実務者が当日詰まらないように、そして経営層が課金を稟議できるように書きます。

まず押さえる結論：このエラーはコードでもクレデンシャルでもない

n8n が「壊れた」と報告されたとき、最初の1分でやることはコード修正でも再デプロイでもありません。executions API（＝n8n の実行履歴を取り出す窓口）から、直近の生エラーログを1行取得することです。

そのエラーメッセージに Execution limit reached. Consider upgrading your plan. が含まれていたら、原因はほぼ確定します。

それは n8n Cloud のプラン上限超過であって、コードもクレデンシャル（＝API接続のための認証情報）も無関係です。
複数のワークフローが同じ時刻から一斉に止まっているときは、個別の不具合ではなく、プラン上限・APIキー期限切れ・外部サービス障害のいずれか。
「n8n Execution limit reached」だけは、エンジニアがコードをいじっても解決できません。基本はプランを上げるか、実行回数そのものを減らすかの二択です（バグや暴走で一時的に超えた場合は、原因修正後にn8nサポートへカウンタのリセットを依頼できることもあります）。

なぜこの順序が効くのか、実際の障害対応の流れで見ていきます。

実話：「コードを追加したら動かなくなった」の真因

ある案件で、SaaSのデータを毎朝ドキュメントへ自動転記するワークフローを運用していました。ある月末、こんな報告が来ます。

「最近ノードを追加してから、リンクがつかなくなりました。元に戻してください」

普通なら、まず追加したノードを開いて中身を確認するでしょう。けれど、先に n8n API を叩いて実行ログを見たところ、こうなっていました。

実行ID	開始時刻	終了時刻	経過	ステータス
#1	09:00:00	09:00:00.034	34ms	error
#2	09:00:00	09:00:00.041	41ms	error
#3	09:00:00	09:00:00.037	37ms	error
...	...	...	...	...

全部30〜40ミリ秒で error 終了している。これはコードのバグでは出ない挙動です。バグなら処理の途中、数百ミリ秒から数秒のところで落ちる。数十ミリ秒で落ちるのは、ワークフローが起動する前の段階で弾かれている証拠でした。

詳細を取得すると、エラーメッセージはこれ。

Execution limit reached. Consider upgrading your plan.

さらに調べると、該当ワークフローの定義は1か月以上前から変更されていませんでした。追加したと言われたノードのコードも、その日から無変更。そして同じアカウントで動いている数十本のワークフローが、全部同じ時刻から error になっていた。

つまり「ノードを追加した」という報告者の記憶と、実際の障害はまったく関係がなかった。真因は、その月の実行回数が契約プランの上限を超えたこと。心当たりを信じて1分でコードを巻き戻していたら、別の不具合を生んで信頼を失っていたかもしれません。

診断の4ステップ：心当たりは脇に置き、ログから読む

この経験から、n8n 障害対応の手順を次のように固定しました。

ステップ1：生エラーログを最初に読む（心当たりは一旦無視）

いちばん大事なのは、報告者が「コード変更が原因だと思う」と言っても、まずログを取りに行くこと。報告者の心当たりが当たっている確率は、経験上それほど高くありません。

n8n MCP（＝Claude などのAIから n8n を直接操作する連携）が入っていれば一発ですが、無くても curl で API を叩けます。

# n8n APIキーは .mcp.json などから取得
N8N_KEY="your-api-key"
N8N_URL="https://your-instance.app.n8n.cloud"

# 直近の実行履歴を取得
curl -s -H "X-N8N-API-KEY: $N8N_KEY" \
  "$N8N_URL/api/v1/executions?limit=10&workflowId=YOUR_WF_ID" | jq

# 特定実行の詳細（生エラーメッセージを含む）
curl -s -H "X-N8N-API-KEY: $N8N_KEY" \
  "$N8N_URL/api/v1/executions/EXECUTION_ID?includeData=true" \
  | jq '.data.resultData.error'

エラーメッセージは要約せず、原文のまま読む。「タイムアウトっぽい」と頭の中で言い換えた瞬間、判断を誤ります。

ステップ2：エラーメッセージのパターンで真因の層を当てる

n8n のエラーで実務で繰り返し当たるのは、ほぼ5〜6パターンです。原文と原因の対応表を手元に置くと、診断が一気に速くなる。

エラーメッセージに含まれる文字列	真因	対処
`Execution limit reached` / `Consider upgrading your plan`	n8n Cloud の月次実行回数上限	プランを上げる or 月初まで待つ or 構成見直し。まれにプラン変更直後の同期遅延で上限未達でも出る（残実行数と矛盾したらサポートへ）
`workflow is not active`	ワークフローが非アクティブ	n8n UI でアクティベート
`Cannot read property of undefined` / `is not a function`	Code/Expression ノードのバグ	直近の変更を確認
`401 Unauthorized` / `403 Forbidden`	認証情報の期限切れ・権限不足	クレデンシャルを再発行
`429 Too Many Requests`	連携先APIのレート制限	リトライ・スロットリング設定
`ECONNREFUSED` / `ETIMEDOUT`	連携先サービスのダウン or ネットワーク	連携先のステータス確認

この中で「n8n Execution limit reached」だけは性質が違う。コードのバグや認証切れは直せば終わりですが、これは「使いすぎ」のサインだからです。直す対象が、コードではなく運用設計そのものになります。

ステップ3：複数ワークフローが同時刻に壊れているか確認する

「特定の1本だけ壊れた」のか「複数本が同時刻から壊れた」のかで、原因の層がまるごと変わります。

1本だけ壊れた → そのワークフロー固有の問題（ノード設定・連携先API変更・個別のクレデンシャル期限切れ）
複数本が同時刻から壊れた → 全体に効く要因（プラン上限・共通APIキー期限切れ・n8n Cloud側の障害）

全アクティブワークフローの直近実行ステータスを一覧化するスクリプトを置いておくと、この判定が10秒で終わります。

# 全アクティブWFの直近実行ステータスを一覧化
curl -s -H "X-N8N-API-KEY: $N8N_KEY" "$N8N_URL/api/v1/workflows?active=true" \
  | jq -r '.data[] | .id + " " + .name' \
  | while read id name; do
      status=$(curl -s -H "X-N8N-API-KEY: $N8N_KEY" \
        "$N8N_URL/api/v1/executions?workflowId=$id&limit=1" \
        | jq -r '.data[0].status // "none"')
      echo "$status  $name"
    done | sort

error がずらっと並んでいたら、共通要因を疑う。「n8n Execution limit reached」かどうかは、ここでほぼ見当がつきます。

ステップ4：「コードのせいではない」と早めに伝える

これは技術というよりコミュニケーションの話。でも軽視できません。

報告者は「あの変更のせいで止まった」と思い込んで連絡してきます。原因がプラン上限だと分かったら、なるべく早く「コードは関係ありません、実行回数の上限に達しています」と伝える。これを言わないと、相手は「とりあえず巻き戻したい」と言い出す。無関係なロールバックは新しい不具合を生むだけでした。

ここまでが、エラーを見てから当日中に原因を確定させるまでの動き。次は、このエラーに繰り返し当たるようになったときの話です。

「n8n Execution limit reached」に何度も当たるなら、運用を見直す合図

一度きりなら、月初を待つか一時的にプランを上げれば済みます。問題は、毎月のように同じエラーが出るようになったとき。これは「自動化が育って、想定より実行回数が増えた」という成長のサインでもあります。ここからは課金で上げるか、構成で逃がすかの判断です。

Before / After：放置と対処で何が変わるか

	上限に当たり続ける（放置）	対処後
自動化の安定性	月末に止まり、復旧まで業務が滞る	上限内 or 上限の外に逃がして安定
月のコスト	上位プラン課金 or ダウンタイムの損失	実行回数に見合った最小コスト
原因の見え方	毎回「また止まった」で消耗	どの処理が重いかが見える
担当者の負荷	月末ごとに調査・説明	仕組みで吸収

まず「どのワークフローが実行回数を食っているか」を出す

課金か構成見直しかを決める前に、実行回数の内訳を見ます。多くの場合、回数の大半を数本のワークフローが占めている。原因が偏っているなら、その数本だけ対処すれば上限内に戻ることも多いです。

実行回数を膨らませる典型は3つ。

回数を食う原因	例	効く対処
高頻度トリガー	1分おきのポーリング（＝定期的に外部を見に行く処理）	間隔を伸ばす／Webhook（＝向こうから通知をもらう方式）に変える
ループの分割実行	100件を1件ずつ実行して100回計上	バッチ（＝まとめて処理）にする
無駄な空振り	取得0件でも起動して1回計上	取得有無を先に判定して早期終了

ここを直すだけで実行回数が大きく減ることがあります。課金の前に、まず内訳を出す。

課金で上限を上げるか、重い処理を逃がすか

内訳を見たうえで、次の3つから選びます。安さだけで決めないのがコツです。

選択肢	向くケース	注意点
上位プランに課金して上限を上げる	全ワークフローが等しく必要で、回数も妥当。すぐ安定させたい	自動化が増えるたびに上限に再到達する。根本対処にはならない
重い処理だけ別構成に逃がす	数本が回数の大半を食っている。連携の本数は今後も増える	逃がす先（サーバーレス等）の構築知識が要る
不要・低頻度のワークフローを止める	「念のため」で動かしているものが多い	何を止めてよいかの棚卸しが必要

上位プランに課金は即効性がある反面、自動化が増えればまた上限に当たる、いわば対症療法です。一方、回数を食う重い処理を n8n の外に出してしまえば、n8n は軽い連携だけを担うようになり、上限に当たりにくくなる。たとえば「定期的に大量データを取得して加工する」ような処理は、n8n に置き続けるより別の実行環境に逃がすほうが安定します。この見極めについては、n8nからCloud Runへ段階的に移行する判断材料を別記事で整理しているので、構成見直しを考えるなら合わせて読んでください。

総コストで見る：月額プランだけが費用ではない

課金を稟議するとき、月額プランの差額だけ見ると判断を誤ります。次の4つを分けて見てください。

コストの種類	規模感	いつ発生するか
月額プラン差額	上位プランへの差額（月額数千円〜）	課金を続ける限り毎月
ダウンタイムの損失	止まっている間の業務停滞・手戻り	上限に当たるたび
構成見直しの初期工数	重い処理を逃がすなら半日〜数日	見直し時に1回
棚卸し・運用設計	不要WFの整理、実行回数の監視	最初に1回＋年数回

「月数千円のプランアップで済む」と見えても、自動化が増え続ける前提なら、いずれ上の階のプランに乗り換える話が繰り返されます。回数を食う処理が特定できているなら、一度の構成見直しで上限から距離を取るほうが、長い目で安くつくことが多い。逆に、連携が当面増えない・すぐ止まりを直したいだけなら、課金が素直です。

自社で対処するか、外注するか

「n8n Execution limit reached」への対処は、レベルがいくつかあります。どこまで自社で持つかで判断が分かれます。

判断軸	自社向き	外注向き
API でログ・実行回数を確認できる人がいるか	いる	いない（UI だけでは内訳が見えにくい）
重い処理を別構成に逃がす知識があるか	ある	ない（サーバーレス等の構築が必要）
今後も自動化を増やしていくか	増やす（監視・運用設計を内製したい）	当面は現状維持

月初を待つ・低頻度WFを止める程度なら自社で十分です。一方、回数の内訳を出して重い処理を別環境に逃がす構成見直しは、クラウドの知識が要る。ここに触れる人が社内にいないなら、外注したほうが速くて安全でした。

こんなケースは無理に対処しないでいい

正直なところ、対処の費用対効果が薄い場合もあります。

上限超過が年に1〜2回だけ：構成見直しの工数より、月初を待つほうが安い
自動化が今後増える見込みがない：プランアップで十分。逃がす構成は過剰
そもそも止まっても困らないワークフロー：止めて棚卸しの対象にする

「毎月のように止まる」「自動化を事業の根に置いている」ほど、構成見直しの効果が大きくなります。逆に、たまにしか当たらないなら待てばいい。ここを冷静に切り分けるほうが、無駄な投資を避けられます。

やってしまいがちな失敗

n8n 障害対応で繰り返し見る失敗を挙げておきます。

失敗1：報告者の心当たりから捜査する

「ノードを追加してから動かなくなった」と言われて、そのノードから読み始める。半分以上は的外れでした。ログから入る、を徹底すれば避けられます。

失敗2：1件のエラーだけ見て原因を断定する

たまたま見た1件が 429 Too Many Requests だったから「レート制限ですね」と返す。実は同時刻に他のワークフローが全部「n8n Execution limit reached」で死んでいた、ということがあります。最低でも直近10件、できれば全アクティブワークフローの直近1件を見る。

失敗3：上限超過に課金で蓋をし続ける

止まるたびにプランを上げるのは、いちばん手軽で、いちばん根本から遠い。実行回数の内訳を一度も見ないまま課金を繰り返すと、コストだけ膨らんでまた上限に当たる。最低一度は「どのワークフローが回数を食っているか」を出してから、課金か見直しかを決めるのが安全です。

まとめ：診断は「心当たり < ログ」、対処は「課金 vs 構成見直し」

n8n が止まったときに最速で原因にたどり着く順序はこうです。

生のエラーメッセージを取得する（コード調査の前に）
エラーパターン表で真因の層を特定する（個別バグかシステム要因か）
複数ワークフローが同時刻に壊れているか確認する（広域要因のシグナル）
真因を報告者に早く伝える（無駄なロールバックを防ぐ）

そして「n8n Execution limit reached」に繰り返し当たるようになったら、それは運用を見直す合図です。

まず実行回数の内訳を出す（数本が大半を食っていることが多い）
高頻度トリガー・ループ分割・空振りを直すだけで上限内に戻ることがある
それでも足りないなら、課金で上げるか・重い処理を別構成に逃がすかを総コストで判断する
上限超過が年1〜2回なら、無理に対処せず待つのも正解

このエラーは、n8n を本格運用するチームなら一度は出会います。出会ったときに「課金で即決するか、構成を見直すか」を事前に決めておくと、当日のダウンタイムも、その後のコストも最小化できる。

n8n がよく止まる・誰も直せないなら

「うちの n8n がしょっちゅう止まる」「Execution limit reached が出ても、課金していいのか構成を変えるべきか判断できる人がいない」。そういう状態は、最初の運用設計で決まることが多いです。

f2t.jp では、n8n の障害対応から、実行回数の内訳を出して重い処理を逃がす構成見直し、止まったときにすぐ復旧できる運用体制づくりまで一貫してお手伝いしています。まずは「どのワークフローが上限を食っているか・課金と構成見直しのどちらが自社に合うか・止まったとき誰が直すか」を一緒に整理するところから始められます。お問い合わせフォームからご相談ください。