大家好，
希望有人能幫忙或至少指點我正確的方向。
我的 n8n Cloud 工作區已經離線超過一小時，一直顯示經典的 503「工作區正在重啟」畫面，但它顯示我的實例在線。我很快就要展示這個工作流程的演示。
發生了什麼： 我第一次運行我的工作流程，它涉及 Gmail 觸發器下載 PDF 附件 + 3 個 AI agent 節點（Claude/Anthropic）。看起來它在首次運行時達到了內存限制，工作區就再也沒有恢復過。
我已經嘗試過的：
-
等待、刷新、不同的瀏覽器、無痕模式 — 仍然是 503
-
檢查 status.n8n.cloud — 沒有全球事件
-
手動重啟實例。
-
聯繫支持 — 收到一個 AI 機器人的回覆，告訴我「優化我的工作流程」。我已經要求升級給人工，但還沒有回覆。
令人沮喪的部分： 我知道修復方法是什麼（減少令牌限制、以不同的方式處理附件）— 我只是無法進入編輯器應用它，因為工作區已經宕機。
有人經歷過這種情況並找到無需等待支持就能讓實例恢復的方法嗎？有沒有辦法從管理面板強制重啟它，我是否遺漏了什麼？
任何幫助都非常感謝 
我的 n8n 設置信息：
@PaulRocks 503 stuck-loop 通常表示你的 pod 在重啟時因為 OOMing 而卡住,因為當 n8n 將其恢復時,失敗的工作流會自動觸發——它會崩潰、重試、再崩潰。你有沒有試過在 app.n8n.cloud 管理員中使用 Suspend → Resume 循環?這是 cloud 唯一公開的自助式強制重啟方式,而 suspend 步驟可以防止自動觸發,讓 pod 在任何工作流運行之前乾淨地啟動。
感謝提示。我試過從管理面板中使用「重新啟動工作區」按鈕，但結果相同，仍然卡在503迴圈中。這證實了你所說的，pod在重新啟動時在任何東西加載之前就崩潰了。
老實說，我正在考慮只是創建一個新的n8n Cloud帳戶，從頭重建工作流程來趕上本週的演示截止時間，但這會讓我付出第二筆訂閱費用。不理想，但我的選擇已經不多了。
或者升級目前的方案可能是唯一的真正修復，因為會有640 MIB？
N8N支援一般需要多長時間才能回答？如果是一天內，我可以等待。如果是兩天或更長時間，這對我來說會非常複雜。
@PaulRocks 先別升級或新開帳戶，技術支援通常可以重啟 pod。寄信到 help@n8n.io，主旨寫「URGENT 503 crash loop」並附上你的實例 URL，提一下你已經知道工作流程是 OOM 的原因，只需要重啟 pod 並在恢復時將工作流程設為非作用中。這樣就不會立刻再崩潰，你有時間修復後再重新啟動。
真正的潛在問題是記憶體壓力——Gmail 附件下載加上 3 個 AI 節點堆積在記憶體裡，對於入門方案來說太重了。等你恢復後，要嘛簡化附件處理，要嘛升級方案。先示範，最佳化放後面。
更新已恢復運作 
感謝協助
快速提問 — 我應該修改工作流程的哪些部分，以確保在 Starter (320 MiB) 上不會再發生這種情況？
目前設定：
你提到停用 downloadAttachments 並改為透過二進位端點進行串流 — 你能解釋一下實務上是如何運作的嗎？我只需要稍後在實際需要讀取附件時按 ID 參考它們嗎？
我也樂於接受有關 Cloud 上 AI 密集型工作流程的任何其他記憶體最佳化提示。再次感謝
是的，完全同意——在 Gmail 觸發器上關閉 downloadAttachments，這樣它只會觸發元資料（訊息 ID + 附件 ID + 檔案名稱）。下游的話，在 SplitInBatches 迴圈內添加一個 Gmail「取得訊息附件」節點，批次大小設為 1，這樣記憶體裡一次只有一個 PDF，而不是全部 11 個堆疊在一起。
還有另外兩件事可以試試。如果你不是真的需要那麼長的長度，就把 maxTokens 從 4096/8192 降低到 1024-2048，可以大幅減少每次代理呼叫的記憶體用量。還有在每個 AI 步驟之後放一個 Set 節點，只保留你後續需要的欄位——n8n 預設會將所有輸入資料帶過每個節點，所以每個代理輸出都會堆疊在之前的所有承載資料上面。