使用 n8n API，如何知道工作流是否已發佈且正常運作？

問題
,
1

我找到了一些關於測試工作流程是否正在運行的答案。但我有興趣了解它是否已發佈且正常（像工作流程編輯器視圖中它旁邊的綠色圓點）。

描述問題/錯誤/問題

在筆記本電腦上本地運行 n8n。
背景：建立了一個每 ~10 分鐘觸發一次的工作流程。檢查我的電子郵件，選擇一些並總結它們，然後提交到 RocketChat 頻道。
不幸的是，發生了許多錯誤，導致它「未發佈」（例如：郵件提供商錯誤、LLM 錯誤、筆記本蓋子關閉 → n8n 進入睡眠狀態等）。
因此，我建立了一個輔助工作流程來重新啟動主工作流程：

  • 主工作流程中的節點發生任何錯誤時
  • n8n 啟動時（n8n 容器在開機時啟動）

但我仍然遇到主工作流程停止的情況。我想添加第三種情況：

  • 每 1 小時觸發一次，檢查工作流程是否「關閉」，如果是，重新啟動它。

當我使用 API 節點檢索主工作流程時，我可以檢查「workflowPublishHistory」或「active」。不幸的是，即使工作流程處於錯誤狀態（編輯器視圖中的紅色圓點），它們都是真/已激活。
由於我特定的設置：

  • 我不能只檢查我的主工作流程是否已發佈
  • 我不能只檢查它是否正在運行，就像我在此處找到的帖子一樣，因為我的工作流程可能在兩個 10 分鐘觸發之間「睡眠」。

所以我的問題是：如何使用 n8n API 節點獲得與編輯器模式中工作流程旁邊顯示的紅色/綠色/黃色圓點相同的信息？

n8n 設置的信息

  • n8n 版本： 2.45.7
  • 數據庫（默認：SQLite）：默認
  • n8n EXECUTIONS_PROCESS 設置（默認：own, main）：own, main
  • 通過以下方式運行 n8n（Docker、npm、n8n cloud、桌面應用程式）：在家製 incus 容器中運行，執行 npx n8n
  • 操作系統：Debian 14 客機 / LMDE 7 主機
2

透過 n8n API 檢查 active 旗標只能告訴你工作流程是否被切換開啟，這就是為什麼即使執行時錯誤觸發紅色指示器，它仍然保持為 true。若要以程式方式檢查健康狀態，你應該查詢 /executions 端點並過濾 status=error，同時搭配你的工作流程狀態檢查，以驗證上次執行是否成功。請告訴我你的自架設環境使用的是哪個資料庫後端，我可以在這裡為你概述確切的 API 呼叫序列。

3

嘿 @liar666 歡迎加入社群，
n8n API 節點的 Workflow Get 不會公開與 2.45.7 中那個點相同的狀態。編輯器結合了觸發發布狀態與草稿變更和配置問題，因此 active=true 不保證綠點。

啟用默認發布服務後，編輯器使用 GET /rest/workflows/<id>/publication-status。其回應包含 data.status（published、partial、failed、in_progress 或 not_published）和 data.triggers 及啟用錯誤。你可以在登入後於瀏覽器中檢查。這是一個內部工作階段認證路由，因此你的 n8n API 金鑰在那裡無法運作。黃色可能只表示未發布的編輯，發布狀態不保證下一次電子郵件/LLM 執行會成功。當紅點停止時，其工具提示說什麼？

4

來自 API 的工作流程物件有一個 active 標誌，所以在你每十分鐘執行一次時檢查它，如果為 false 就重新啟動。Active 只是告訴你它是否開啟，但不代表它運作正常。拉取最新的執行紀錄並檢查最近是否有成功執行是更好的測試方法。休眠的筆電也會持續造成你的麻煩。

5

感謝。

不幸的是，我無法讓它一直正常運作。

我使用 Http Request 來取得該 URL，但收到 401 Unauthorized 錯誤。

  • 我嘗試使用我的 n8n API 金鑰新增「預定義認證」，但無法運作

  • 我嘗試給予此金鑰更多存取權限（原本設定只有最少權限：僅讀取和啟用工作流程），但仍然無法運作

  • 我嘗試新增自訂 HTTP 標頭，使用「Authorization」和「Bearer [key]」，但仍然無法運作。

有什麼想法知道我哪裡做錯了嗎？

6

@liar666 401 表示請求沒有在 n8n 期望的標頭中攜帶 API 金鑰。在 HTTP Request 節點中，不要使用通用的「Predefined Credential」— 而是將 Authentication 設定為「Generic Credential Type」→「Header Auth」，Name 為 X-N8N-API-KEY，Value 為你的 n8n API 金鑰。或者，如果你的節點版本支援，使用專用的「n8n API」憑證類型。

有幾個需要雙重檢查的地方：金鑰必須在 Settings → n8n API 下建立（不是使用者密碼），如果你的實例位於反向代理後面，請確保代理沒有在到達 n8n 之前刪除 X-N8N-API-KEY 標頭。你可以從同一台機器快速用 curl 驗證：curl -H "X-N8N-API-KEY: <key>" http://localhost:5678/api/v1/workflows — 如果返回 200，金鑰沒問題，問題只是節點如何發送它。