Cloudflare Workflows 保留期缩短后，运行历史该怎么留

Cloudflare Workflows 保留期：下调的是默认值，不是上限

Cloudflare Workflow 是一种由多个步骤组成的持久化作业。平台会保留足够的状态，让任务在等待或重试后继续执行；任务完成或出错后，再按设定的保留期保存这个已结束的实例。

被保留下来的实例，就是排查问题时的运行证据。Cloudflare 实例 API 可以返回状态、参数、输出、步骤详情、尝试次数、耗时和错误。此前某次付款对账、客户数据导入或发布任务若失败，这份记录能帮助团队还原当时究竟发生了什么。

9 月的调整有三条边界：

• 2026 年 9 月 10 日当天或之后创建的 Workers Paid Workflow，已完成和出错实例的状态默认保留 7 天。
• 已有 Workflow 继续沿用当前的保留规则。Cloudflare 没有追溯缩短旧 Workflow 的保留期。
• Workers Free 仍为 3 天，这既是默认值，也是上限。

Paid 方案仍允许最长保留 30 天。因此，Cloudflare 降低的是默认值，不是最大值。

理解这一点，也就能解释文档中一个容易让人困惑的冲突。定价页面 最后更新于 7 月 21 日，仍称 Paid 方案的默认保留期为 30 天。Workers API 参考文档 更新于 8 月 12 日，其中写道，不提供保留设置时将采用账户上限。这两个页面都早于 9 月 10 日的更新日志。

应以范围更窄、发布时间更晚的规则为准：新建的 Paid Workflow 默认保留 7 天。已有 Paid Workflow 不受影响，Paid 方案的上限仍是 30 天。

7 天如今就是事故发现期限

真正的问题不是 7 天听起来够不够长，而是团队能否在第 7 天之前发现重要故障。

负责付款或订单任务的后端负责人，可能要等到客服或财务对账时才知道记录不一致。如果届时实例已超过保留期，团队手里或许还有外部交易记录，却已经失去 Workflow 的步骤尝试、错误详情和输出，无法还原实际执行路径。

SRE 还需要避开另一个误区。Cloudflare 的 Workflow 指标可以查询 31 天，但这段分析窗口不等于详细实例状态的保留期。指标可以证明发生过一次失败事件，却不能证明旧实例的参数、输出、尝试记录和错误仍然可查。

这与使用 AI Agent 故障分析工具 时的运维原则相同：证据保留期应覆盖从故障发生到有人意识到它很重要之间的延迟。

对服务多位客户的技术负责人来说，风险在于策略不一致。调整前创建并长期运行的客户 Workflow 可能沿用旧窗口，而调整后创建的替代 Workflow 会悄然变成 7 天。即使代码路径看上去没有变化，客户运行手册也可能已经写错。

把低价值的成功历史与高价值的错误历史分开

Cloudflare 提供两项控制，正是为了让两类历史分开处理：

• successRetention 决定成功完成后，状态继续保存多久。
• errorRetention 决定出错或终止后，状态继续保存多久。

成功运行通常会在其他地方留下持久的业务结果，例如订单行、对象键、已发送消息 ID 或已完成的导入记录。如果外部系统才是事实来源，那么较短的成功保留窗口往往已足够应对近期客服查询和重放检查。

出错运行则不同。真正有价值的，往往正是那条未完成的执行路径。调查人员可能需要失败步骤、此前的尝试、输入参数和中间输出。如果故障可能很晚才暴露，与其让所有成功运行保留同样久，不如为错误历史设置更长、也更容易解释的窗口。

官方更新示例 直接展示了这种拆分方式：

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

这只是示例，并非适用于所有团队的建议。错误窗口应根据最迟可能发生的发现与调查延迟来定；成功窗口则取决于真实结果写入事实系统之后，运维人员还需要查看 Workflow 记录多久。

算 Cloudflare Workflows 存储费用时，必须拆出活跃状态

Cloudflare 以 GB-month 为单位对 Workflow 存储计费。Workers Paid 每月包含前 1 GB-month，超出部分按每 GB-month $0.20 收费。Cloudflare 的计算方法是：在一个 30 天账单周期内，对每天的峰值存储取平均值。

存储总量涵盖运行中、休眠中、出错和已完成的实例。因此，缩短结束状态的保留期可以减少已完成状态占用的存储，却不会清除仍在运行或休眠的任务状态。

当前定价页面写明，Workflows 的步骤与存储计费从 2026 年 8 月 10 日开始执行。此前 7 月的计费通知只承诺不会早于这一日期收费。现行页面确认了已公布的开始日期，但仍不能证明任何特定账户的下一张账单会显示什么。

下面是一套明确标注为假设的模型，不是 Cloudflare 基准，也不是承诺能够省下的金额。

假设在稳定业务量下，成功运行每天新增 1 GB 待保留状态。无论采用哪种方案，活跃、运行中和休眠实例还会贡献 0.5 GB-month。为了单独观察成功保留期这一杠杆，比较中不计入错误状态存储。如果 errorRetention 仍设为 30 天，应先测量这部分状态，再在两边加入相同的错误历史项。

模型中的差额是 $4.60，这正说明为什么必须标清输入条件。步骤输出很小的团队，几乎可能省不到钱；运行量高、持久化结果又大的 Workflow，则可能有大得多的成功状态保留项。新默认值改变的是乘数，真正决定账单的仍是状态大小和完成速率。

必须坦诚面对的上限

Paid 方案的最大保留期仍是 30 天。如果客户、监管方或月度对账可能在这个窗口之后才暴露问题，Workflow 实例状态就不能成为唯一档案。应把真正需要的最少证据导出到另一个拥有独立保留与访问策略的系统中。

错误状态保留得越久，占用的存储也越多。正确策略不是“错误永久保存”，而是保留足够长的时间，以便发现问题并还原事故；此后留下精简的持久记录，例如实例 ID、Workflow 版本、时间戳、状态、脱敏后的错误，以及受影响的业务对象。

缩短成功保留期也有前提：成功结果必须已经存在于可信系统中。如果某次操作是否发生只记录在 Workflow 输出里，更早删除输出会同时减少存储和证据。

按实例覆盖设置同样可能让策略变得支离破碎。拥有多条创建路径的服务团队，即使在控制台正确配置了默认值，仍可能有某个调用方请求不同窗口。保留策略应该进入代码审查、运行手册和成本模型，而不能只留在控制台设置里。

现在该怎么做

如果你在 9 月 10 日当天或之后创建了 Paid Workflow，故障可能超过 7 天才传到负责人手里，或者已完成状态已成为明显的存储项，就应该在本周采取行动：分别设置成功与错误保留期。

如果 Workflow 仍是低流量试点，且保留状态没有超出包含的 1 GB-month，可以暂缓做成本优化。但策略仍应明确，因为即使超额存储费用为零，调查窗口依然重要。

如果 Workflow 早在 9 月 10 日之前就已存在，默认值调整不会影响它。Workers Free 也没有变化，默认值和上限仍为 3 天。不过，只要业务需要在平台窗口之外继续调查，这两种情况都不能替代外部记录。

周一，审计每一条新建 Workflow 的路径。明确设置 successRetention 和 errorRetention，再触发一次安全的失败，并确认其详细状态最晚可以查看到哪一天。在第一次真实事故替你检验之前，先把这个日期写进运行手册。

订阅 newsletter，持续获取下一项值得行动的平台变化。