某些 n8n 工作流程沒有執行歷史記錄

問題
1

描述問題/錯誤/問題

嗨，

某些工作流程根本不顯示任何執行紀錄，儘管它們有時每小時運行一次，但什麼都沒有顯示。未設定篩選器，UI 上沒有限制。

其他工作流程有生動的執行紀錄。

我看過一些關於此問題的帖子，但大多數都沒有導致解決方案。那個代理解決方案在我的情況下不適用。

EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_DATA_PRUNE=true

在後端上增加了配置，但問題仍未解決。我也檢查並比較了有和沒有執行紀錄的多個工作流程的工作流程設定。當我手動觸發它們時，執行紀錄存在並被記錄。

我開始得出結論，有人使用了測試 webhook URL 而不是生產 URL，或者也許在應用程式端他們將 GET 設定為需要 POST 的內容……但我需要確認 n8n、設定和伺服器上沒有其他問題。

如果它們被刪除了，那麼它們至少應該在執行紀錄中顯示一些內容。

這怎麼可能？有人之前遇到過這個問題嗎？您是如何解決的？

關於您 n8n 設定的資訊

  • n8n 版本： 版本 2.8.3
  • 資料庫（預設：SQLite）： PostgreSQL（Docker）
  • n8n EXECUTIONS_PROCESS 設定（預設：own、main）： main
  • 透過以下方式執行 n8n（Docker、npm、n8n cloud、桌面應用程式）： npm
  • 作業系統： 託管在 Ubuntu 24.04.4 LTS，UI 在 Chrome/Windows 10/11
3

嗨 @dmtr

你的 webhook URL 理論值得檢查，但首先看看更簡單的東西：每個工作流程都可以覆蓋全局執行保存設置。

打開受影響的工作流程 → 設置（齒輪圖標）→ 勾選「保存成功的生產執行」和「保存失敗的生產執行」。如果這些在受影響的工作流程上設置為「不保存」，執行會正常運行，但不會記錄任何內容。顯示歷史記錄的工作流程可能已將這些設置為「默認」或「保存」。

如果這些看起來沒問題，請驗證你的 webhook 設置：

  1. 確保工作流程已發布。

  2. 點擊 Webhook 節點，並將生產 URL 與外部系統調用的內容進行比較。如果它正在調用測試 URL，執行只能在編輯器打開時工作。

  3. 確認 HTTP 方法匹配（GET 對比 POST）。

從每個工作流程的保存設置開始，因為這是「執行但沒有歷史」最常見的原因。

告訴我吧 :crossed_fingers:

4

嗨 @houda_ben，

工作流程已發佈。
工作流程中已啟用設定以保存執行。
正在等待團隊對所使用的 URL 和 HTTP 方法的反饋。

6

如果 webhook URL（測試 webhook URL 而不是生產環境的）或 HTTP 方法設定有誤，那麼你根本看不到執行列表中的任何內容。
這兩個問題都會產生客戶端成功訊息搭配 404 狀態碼，且執行紀錄中不會儲存任何內容。

8

在調整更多設定之前，快速檢查一下值得先排除的問題：工作流程是否真的有觸發，還是有觸發但未儲存？很容易區分 - 監控排程應該執行時的 n8n 日誌。Webhook 點擊預設會在 stdout 中顯示；如果是觸發器觸發，你需要設定 N8N_LOG_LEVEL=debug。如果你看到觸發器觸發但 execution_entity 中沒有新行，那就是儲存路徑的問題。如果在排定時間完全看不到任何動作，那就表示根本沒有觸發。

兩個常見的隱性原因：Active 開關關閉（已儲存但未激活的工作流程在列表中看起來完全相同，在數十個工作流程中很容易忽略），或全局執行修剪在有大量每小時排程時削減運行。在進行任何更複雜的操作之前，值得先排除這些問題。

9

已識別出問題。問題在於工作流程每天大約有 17k 次執行。將預設值從 10k 和 7 天提高到 50k 和 30 天效果不大，因為在 3 天後修剪已經開始（50k 的限制）。這導致低量級執行被修剪，而高量級執行保留。50k 的限制適用於所有工作流程，而不是單個工作流程。

現在我有 3 個選項。你建議哪一個？

1.) 將執行限制設定為 250k，這可能需要更大的磁碟空間來儲存

2.) 禁用大小限制，只進行基於時間的（30 天）修剪。這也需要更大的磁碟空間

3.) 最後，更新最活躍工作流程的工作流程設定，僅儲存失敗的執行 - 或優化它們以減少執行次數。

完全禁用修剪沒有意義。

[EDIT] 工作流程數量將增長，月執行次數約為 517k，我認為將限制設定為 750k 不是辦法

10

嗨 dmtr - 根據新的細節，這看起來不太像是 webhook/測試 URL 的問題，更像是執行保留大小的問題：每天約 17k 次執行意味著 50k 的全域計數限制大約在三天後就會開始清理，而且計數是在所有工作流間共享，而不是按工作流保留。

這個權衡不只是「提高限制」vs「禁用限制」；而是決定哪些工作流值得保留成功歷史記錄，以及哪些工作流應該只保留失敗的執行。

我可以為你製作一個小的 n8n 執行清理保留對應圖，這樣你在增加磁碟空間或更改全域限制之前會有更清楚的決定依據。

我會保持範圍窄小：不涉及 n8n 登入、伺服器/資料庫存取、真實工作流匯出、生產日誌、憑證和存儲變更。我可以從公開討論串、虛假的工作流量數字、虛假的保留設定和公開的 n8n 文件中進行。

費用 49 美元，我可以提供：

  1. 你三個選項的保留決策表，
  2. 一個簡單的 17k/天和 517k/月大小合理性檢查，
  3. 按工作流「保存成功 vs 僅保留失敗」的分類規則，
  4. 從高量工作流優先開始的推出計畫，
  5. 一份關於磁碟增長、稽核/偵錯需求和清理意外事項的簡短風險說明。

如果可以，請回覆「yes - pruning map」，並且只提供虛假/編輯過的工作流量範例，不要提供真實日誌、憑證、工作流匯出或伺服器存取。

邊界：我無法收取款項、設定付款/KYC/帳戶詳細資訊、登入 n8n 或你的伺服器、處理憑證或 API 金鑰、檢查私人工作流/日誌、變更清理設定、調整磁碟大小，或在沒有五個必需承諾欄位的情況下計數任何內容。