limit must be 250 以下の直し方

n8n の「n8n」ノード（自分の n8n の、ワークフローや実行を読むためのノード）で、実行の一覧を取ろうとしたら、400 のエラーになった。

request/query/limit must be <= 250

原因は、取得する件数（Limit）に、250より大きい数を入れていることです。直し方は、「Return All」（全件を取る）をオンにすることです。

何が起きたか

筆者は、自分の n8n の、ワークフローごとの実行回数を数える、見張りのワークフロー（自動化の診断書）を作っていました。「n8n」ノードで、実行の一覧（Execution の Get Many）を取るとき、件数（Limit）に、250より大きい数を入れました。

• 実行すると、400 のエラーになり、request/query/limit must be <= 250 と出ました
• エラーの文言は、「limit は、250以下でなければならない」という意味です。250より大きい数は、受け付けられません

直し方

1. 「n8n」ノードを開きます（Resource：Execution、Operation：Get Many）
2. 「Return All」（全件を取る）を、オンにします
3. 「Limit」の欄は、Return All をオンにすると、設定の対象から外れます（診断書のワークフローの JSON にも、limit の値は、入っていません）

筆者の診断書のワークフローは、この形（Return All：オン）で動いています。

全件を取る前に、知っておくこと

保存されている実行が多い n8n では、全件を取ると、時間がかかり、メモリを使うかもしれません。

• 筆者の環境では、保存されている実行は、数百件で、全件の取得で、問題ありませんでした（ワークフローは62本）
• 実行が、数千〜数万件ある n8n では、重くなる可能性があります（筆者は、試していません）
• 範囲を絞るなら、フィルター（ワークフローの ID や、状態）を使います。取る量が減ります

もう1つ、n8n は、古い実行の記録を、自動で消します。 そのため、「過去30日の実行回数」のような数は、実際より小さく出ます。診断書では、いま残っている、いちばん古い実行の日付も、一緒に出しています。

「250」という上限について

エラーの文言から読める範囲では、250以下なら、受け付けられるようです（筆者は、250ちょうどで、試していません）。「Return All」を使わずに、250件ずつ、何回かに分けて取るやり方も、考えられますが、筆者は、試していません（取り方が、複雑になります）。

確認していないこと

• Limit を250ちょうどにしたときの動き
• 250件ずつ、分けて取るやり方（n8n の API を、HTTP Request ノードで、直接呼ぶ形）
• 実行が数千件以上あるときの、全件取得の重さ
• n8n クラウドでの、同じ上限
• 公式のドキュメントでの、この上限の記載（筆者は、エラーの文言から、読みました）

次に読む

• 実行回数と、認証を見張るワークフローは 自動化の診断書
• 実行の履歴が、増え続ける問題は n8nの実行履歴の保存と削除
• 失敗しても、止まらない作り方は n8nのエラー処理
• 認証が切れたときの落とし穴は n8nの「Access could not be refreshed」