Cloudflare Workflows 2026 計費怎麼算？用四個維度盤點 steps、state 與 instance 清理

先分清楚四個計費維度#

Cloudflare Workflows 的 pricing 頁面列出四個維度：CPU time、requests、storage 與 steps。這些指標回答的問題不同，不能只看 Workflow instance 數量推估成本。

官方特別說明，step count 不包含 rollback handlers 或 retries；但每個 Workflow 的步驟設計仍會影響執行路徑與 state。要做預估，不能只把程式碼裡出現的 step.do() 乘上 instance 數，還要把條件分支與等待流程列入。

Free 與 Paid 的額度#

目前官方 Workflows pricing 列出的額度如下：

Paid plan 的 requests 與 CPU time 也有自己的月度包含額度；不能因為 steps 或 storage 有額度，就把整個 Workflow 視為零成本。正式帳單仍以 dashboard 與 pricing 頁面為準，因為方案額度與計費說明可能會更新。

Storage 怎麼算，為什麼 retention 很重要#

Cloudflare 以 GB-month 計算 Workflow storage，並用 30 天計費期間內每日的 storage peak 取平均。running、errored、sleeping 與 completed instances 都可能計入；因此「流程已完成」不等於 state 立刻不佔 storage。

官方目前的預設 state retention 是 Free plan 3 天、Paid plan 30 天。若任務完成後不需要長期保留完整 state，可以評估更短的 retention，但要先確認事故排查、重試與稽核需求。刪除 instance 可以釋放它的 state，卻不是把過去已計入的 storage 用量或其他 SKU 費用回溯抹除。

我會為每種 Workflow 寫下這三個問題：

• 失敗的 instance 要保留多久，才足夠重現問題？
• 完成的 instance 是否需要保存完整輸出，還是只留外部資料的識別碼？
• state 裡是否放入不應長期保存的 token、個資或第三方回應？

不要為了少一點 storage 直接刪掉所有錯誤紀錄。先把敏感資料與可重建資料分開，再決定 retention，成本與可觀測性才不會互相犧牲。

delete() 與 deleteBatch() 解決什麼問題#

2026 年 9 月的 Workflows 文件新增了兩種 instance 清理方式：

1
// 單一 instance：刪除 state，並停止正在執行的 instance
2
await env.MY_WORKFLOW.delete(instanceId);
3

4
// 批次清理：一次最多 100 個 instance ID
5
const result = await env.MY_WORKFLOW.deleteBatch(instanceIds);
6
// result: { deleted, errors }

它們的共同語意是：刪除 instance 的持久化 state；如果 instance 正在執行，也會停止目前執行。刪除是破壞性操作，不會替你執行 rollback handlers，也不會讓程式在 self-delete 的 await 後繼續跑。若你只是想暫停、終止後保留狀態，或從頭重跑，應使用對應的 pause、terminate 或 restart API，而不是直接 delete。

deleteBatch() 一次接受 1 到 100 個 ID，回傳已刪除與錯誤項目的結果。批次清理前要先：

1. 把要清理的 ID 寫入可追蹤的清單，避免把仍需稽核的 instance 混進去。
2. 先排除重複 ID，並以最多 100 個分批。
3. 保存 deleted 與 errors，對失敗項目做人工檢查或重新排程。
4. 清理後回到 dashboard 檢查 state 用量，不要把 API 成功回應直接當成帳單已即時下降。

Wrangler 4.125.0 以上也能用 npx wrangler workflows instances delete 清理 instance，支援指定 ID、JSON 檔案中的 ID、latest 與 --local。實際執行前先用同版本的 --help 確認參數，並在 production 把 command、操作者與輸入清單留下紀錄。

Delete、terminate、pause、restart 怎麼選#

這張表的重點是成本和生命週期是兩個問題。若目標是減少未來 storage，delete 才是清理動作；若目標是暫停事故中的流程，先用 terminate 或 pause，避免因為刪除 state 而失去除錯證據。

先用四個數字做月度試算#

可以把每個月超過包含額度的部分分開計算。以目前官方 pricing 的單位表示，概念公式如下：

1
steps    = max(0, 月 steps - 500,000) / 100,000 × 0.80
2
storage  = max(0, GB-month - 1) × 0.20
3
requests = max(0, 月 requests - 10,000,000) / 1,000,000 × 0.30
4
cpu      = max(0, CPU ms - 30,000,000) / 1,000,000 × 0.02

例如一個月有 650,000 steps、1.5 GB-month、12,000,000 requests 和 35,000,000 CPU ms，四項超額的示意加總是 $1.20 + $0.10 + $0.60 + $0.10 = $2.00。這只是 Workflows 四個維度的估算，不包含其他 Workers 或帳號產品費用，正式帳單仍以 dashboard 與 pricing 頁面為準。

如果需要用量趨勢而不只看單次部署結果，請固定時間區間、Workflow 名稱與成功／失敗路徑，再比較調整 retention、步驟或清理策略前後的數據。不要只用刪除 API 的呼叫次數判斷成本是否下降。

先找出最容易放大用量的 Workflow#

在 repository 根目錄做一次靜態盤點：

1
rg -n \
2
  'step\.(do|sleep|waitForEvent)|WorkflowInstanceCreateOptions|retention|deleteBatch' \
3
  src test tests . \
4
  --glob '!node_modules/**' \
5
  --glob '!dist/**'

接著把每個命中點放入三類：

1. 高頻短任務：例如 webhook、排程或每次使用者操作都建立 instance。這類任務先看每日／每月 instance 數與固定 steps。
2. 長時間等待：使用 step.sleep() 或 step.waitForEvent()，等待本身不會持續消耗 CPU，但可能讓 state 保留更久。
3. 大 state 或長 retention：每個 instance 儲存大量輸出，或保留 errored、completed instance 的時間很長。這一類優先檢查 state 是否真的需要完整保存，再設計可審計的清理流程。

這個盤點的目的不是把所有步驟壓成一個函式。拆成 steps 能提供 retry、durable execution 與觀察性；要縮減的是沒有帶來可驗證邊界、卻反覆執行或保存過多資料的部分。

啟用前的驗證清單#

• 在 Cloudflare dashboard 查看 Workflows usage，記下目前的 instance、steps、requests、CPU 與 state 趨勢。
• 為每個高頻 Workflow 計算一個完整成功流程的 steps，另外標示分支、重試與等待。
• 檢查 state 的平均大小與 retention；不要只看 instance 數量。
• 將 requests、CPU time、steps、storage 分成四欄，避免把不同 SKU 混成單一「每次執行成本」。
• 若要調整步驟、retention 或刪除策略，先在非正式環境驗證失敗恢復、人工等待與 dashboard 資料是否仍足夠。
• production 清理前先 dry-run 產生 ID 清單，核准後才呼叫 deleteBatch()，並保存錯誤結果。

真正要完成的不是把所有 Workflow 重寫，而是知道哪幾個流程會讓 steps 或 state 失去控制，並能用實際 dashboard 數字驗證調整結果。清理 API 是生命週期工具，不是成本回溯工具。

常見問題#