n8nで処理は動いたように見えるのに、Executionsで履歴を見つけられない。最初に、実行されなかったのか、保存されなかったのか、保存後に削除されたのかを分けます。履歴が空という表示だけから、すぐにpruning設定を変更する必要はありません。
この記事は、運用担当者がworkflowと時刻を特定し、閲覧範囲・保存設定・自動削除を照合する手順です。実行済みか分からない処理を、確認のために何度も再実行することは避けます。メール送信や登録が既に成功していれば、再実行が二重処理になるためです。
目次
探している実行の識別情報をそろえる
対象インスタンス、workflow、発生時刻とタイムゾーン、manual／production、期待した入力を記録します。execution IDを控えている場合は、それも使います。外部サービスで結果が見えるなら、そのevent IDと時刻を対応させます。ただし、外部結果があることだけで、探しているn8nのrunと同一だと断定しません。
表は横にスクロールできます
| 観察 | まず分けること |
|---|---|
| 特定workflowだけ見つからない | workflow指定・project・保存設定 |
| 古い実行だけ見つからない | 表示期間・保持条件・削除 |
| manualはあるがproductionがない | 実行種別ごとの保存とtriggerの起動 |
| 一覧のrunはあるが内容が見えない | nodeデータ保存・redaction・閲覧範囲 |
履歴の欠落と、nodeの入力・出力が伏せられている状態は別です。後者を直すために保存期間を延ばしても、閲覧制御やredactionの原因を解消したことにはなりません。
フィルターとアクセス範囲を先に確認する
現行の公式資料では、OverviewのExecutionsは自分がアクセスできるworkflowの実行を表示し、project内のExecutionsはそのprojectの範囲を表示します。workflow、状態、開始時刻等のフィルターも確認します。別projectの一覧や限定した期間を見ていないかを、保存設定の変更前に調べてください。n8n：View all executions（新しいタブで開く）
対象workflowが削除されている場合も別です。同資料は、workflowを削除するとその実行履歴も削除されると説明しています。似た名前で作り直されたworkflowを開いても、以前の履歴がそこへ移る前提にしないでください。
閲覧権限がない範囲は、設定を変えて見えるようにしようとせず、workflow ID・時刻・確認目的を担当者へ渡します。自分の画面で見えないことと、データが存在しないことは分けて記録します。
実行種別と結果ごとの保存設定を見る
workflow Settingsでは、成功したproduction、失敗したproduction、manual、nodeごとの進捗保存を別に設定できます。特定workflowだけ挙動が違う場合は、インスタンス全体の設定だけでなく、そのworkflowの設定も確認します。nodeデータのredactionも別項目です。n8n：Configure workflow settings（新しいタブで開く）
表は横にスクロールできます
| 設定の対象 | 照合する実行 |
|---|---|
| successful production | 自動起動して成功した処理 |
| failed production | 自動起動して失敗した処理 |
| manual | editorから起動した確認 |
| execution progress | node単位の保存内容 |
| redaction | 保存有無と別に、表示されるデータ範囲 |
今の設定が保存する状態でも、過去のrun時点で同じだったとは限りません。変更履歴や運用記録がない場合は「実行当時の保存設定は未確認」とします。保存を有効にすれば、過去に保存されなかったデータまで戻るわけではありません。
Self-hostedでは、管理者が適用中の環境変数を確認します。例えばEXECUTIONS_DATA_SAVE_ON_SUCCESS、EXECUTIONS_DATA_SAVE_ON_ERROR、EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONSは、保存する実行種別を確認する手掛かりです。設定ファイルの想定値と、実際に稼働しているインスタンスへ適用された値を分けます。全文の環境変数一覧にはsecretが含まれ得るため、診断票には関係するキーと値だけを記録してください。n8n：Executions environment variables（新しいタブで開く）
pruningは経過時間と件数の両方を見る
n8nの自動削除は、保存からの経過時間だけでなく、保存件数の条件も確認します。Manage execution data資料は、完了した実行が年齢条件または件数条件に達した場合に削除対象となること、件数超過では古い実行から削除することを説明しています。設定した保持日数が、すべてのrunをその期間必ず残す保証とは限りません。n8n：Manage execution data（新しいタブで開く）
表は横にスクロールできます
| 確認 | 見たい関係 |
|---|---|
| 年齢条件 | 対象runの完了時刻と保持設定 |
| 件数条件 | 対象インスタンスの保存量と上限 |
| 他workflowの実行量 | 全体の件数増加が古い履歴へ及ぼす影響 |
| 削除の状態 | 一覧にない理由を保存されなかった場合と区別 |
少ない頻度のworkflowでも、別workflowの大量実行により古い履歴が残りにくくなる場合があります。特定workflowの設定だけを見て、全体の件数条件を無視しないことが重要です。runningやwaiting等の状態は、完了実行のpruningと同じ扱いにせず、対象版の公式資料で確認します。
Cloudでは契約上の保持・表示条件とworkflow設定、Self-hostedでは実際の環境変数や運用方針を照合します。別環境の既定値を自分の保証期間として使わないでください。
設定変更より先に、必要な診断情報を決める
履歴を全部長期保存すると、ディスク使用量や個人情報の保存量が増えます。反対に失敗だけ保存すると、成功した処理の追跡に使える情報が減ります。どの業務で何を追跡する必要があるかを決め、event ID、execution ID、時刻、結果等の最小情報と、詳細payloadの扱いを分けます。
既に削除されたデータは、保持設定を伸ばすだけでは復元できません。保存済みコピーやバックアップの有無を権限者へ確認し、履歴を作り直す目的で業務処理を再実行しないでください。削除の停止や上限の変更も、容量・保持要件を確認せずに一律適用する対応にはしません。
次の一件で保存経路を確認する
機密や副作用のない検証ができる環境で、新しい一件について発生時刻、実行種別、結果、execution ID、一覧での見え方を記録します。既存の業務処理を再送する必要がある場合は、先に外部側の処理済み状態を確認します。
完了時は「フィルターで見えなかった」「当時保存対象ではなかった」「保存後の削除条件に該当した」「実行そのものが未確認」を区別し、確認した証拠と残る不明を残します。本文は公式資料に基づく診断手順です。特定のn8nインスタンスへ接続したり、履歴の復旧・削除・再実行を検証したりした報告ではありません。