想想這個情況:
昨天打造的「新客戶自動歡迎流程」實在太強大了!
但就在剛剛...
有個新客戶進來,流程跑到一半,Jira 節點突然因為對方 API 臨時不穩而失敗了。
結果客戶沒收到歡迎信,Slack 也沒人知道有新客戶,完全不知道發生了這場「無聲的慘案」,直到隔天手動檢查資料庫才發現客戶被遺漏了...
這是我們最不想遇到的情況,但我們也知道現實一定會遇到各種情況。
所以!
我們要為 n8n 打造一個專門的「醫護團隊」工作流。
這個流程平常沒事都在休息,但只要你任何一個重要的工作流在執行過程中「受傷倒下」(發生錯誤),這個醫護團隊就會被立刻啟動,自動收集所有案發現場的資訊(哪個流程、哪個節點、錯在哪裡、附上 Log 連結),然後用最快的速度(例如發送到你的私人 Slack 頻道),向你發出警報。
Error Trigger:認識這個只在「出錯時」才會被啟動的特殊觸發器。
Workflow Settings: 如何為你的主要工作流,指定「專屬的錯誤處理流程」。
錯誤診斷:學習如何從錯誤訊息中,讀取最有用的除錯資訊。
第一步:像個工程師一樣思考 —— 為失敗做計畫
在專業的軟體開發世界裡,工程師花在思考「如果失敗了怎麼辦」的時間,絕對不比思考「如何成功」的時間少。
我們的自動化流程,會因為各種無法預測的原因而失敗:對方服務的 API 臨時掛掉、網路不穩、資料格式突然改變...等等。
我們不能假裝它們不會發生,而是要為它們的發生,做好萬全的準備。
第二步:打造你的「醫護團隊」工作流
建立一個全新的、獨立的工作流。
將它命名為,例如 🚨 Master Error Handler。
新增 Error Trigger:
刪掉預設的 Start 節點,點擊 Add Trigger。
搜尋並新增 Error Trigger。你會看到一個紫色爬蟲的節點。
這就是我們醫護團隊的「呼叫器」。它只會在被其他失敗的工作流呼叫時,才會啟動。
了解案發現場資訊:
點開 Error Trigger,你會發現它可以產生一筆「範例錯誤資料」,執行它。
在 Output 中,你會看到 n8n 為你準備好的所有「案發現場」資訊,其中最重要的包含:
workflow.name:哪個工作流出錯了。
execution.error.message:錯誤訊息是什麼。
execution.url:最重要的! 這是一個獨一無二的網址,點擊它,可以直接跳轉到那一次失敗執行的詳細 Log 頁面。
設定警報系統 (Slack 節點):
在 Error Trigger 後,加上一個 Slack 節點。
將它指向一個你的私人頻道,或是專門用來接收警報的 #n8n-alerts 頻道。
使用 Blocks,設計一則清晰的警報訊息:
{{
{"blocks": [
{"type": "header", "text": {"type": "plain_text", "text": "🚨 N8N 工作流執行失敗!"}},
{"type": "section", "fields": [
{"type": "mrkdwn", "text": "*工作流名稱:*\n`{{ $trigger.item.json.workflow.name }}`"},
{"type": "mrkdwn", "text": "*錯誤訊息:*\n`{{ $trigger.item.json.error.message }}`"}
]},
{"type": "section", "text": {"type": "mrkdwn", "text": "👇 **點此連結,立刻前往案發現場** 👇"}},
{"type": "section", "text": {"type": "mrkdwn", "text": "<{{ $trigger.item.json.execution.url }}|🔗 查看詳細執行日誌 (Execution Log)>"}}
]}
第三步:為你的主力艦隊,裝上「自動求救」功能
醫護團隊已經待命,現在我們要告訴我們的「主力艦隊」(例如 Day 24 的新客戶歡迎流程),如果自己不幸沉沒了,記得要按下求救按鈕。
回到你最重要的那個「新客戶自動歡迎流程」工作流。
點擊畫布右上角的 ... ,選擇 Setting。
在 Error Workflow 的下拉選單中,選擇我們剛剛建立的 🚨 Master Error Handler。
儲存並啟用 (Active) 這個工作流。
現在,你可以對你所有重要的工作流,都重複這個步驟。
今天過後,你學會的不是一個新功能,而是一種「專業態度」。
你打造的系統,不再是順風順水時的玻璃大砲,而是裝上了安全氣囊和自動警報系統的裝甲車。
它能在意外發生時,保護你的業務、保護你的數據,並在第一時間通知你,讓你從容地解決問題。
這,就是專業與業餘的巨大分野。
既然我們的流程已經變得「可靠」,明天,我們來探討如何讓它變得更「安全」與「高效」,學習專業人士是如何管理他們的 API Key 與重複使用的程式碼片段。