Cloudflare Workflows: как настроить хранение истории запусков

Изменился срок по умолчанию, а не максимум

Cloudflare Workflow — это устойчивая задача, разбитая на шаги. Платформа сохраняет состояние, необходимое для продолжения работы после ожидания или повторной попытки, а затем ещё некоторое время держит данные завершённого экземпляра — как успешного, так и закончившегося ошибкой.

Этот экземпляр и есть журнал событий для расследования. API экземпляров Cloudflare возвращает статус, параметры, результат, сведения о шагах и попытках, время выполнения и ошибки. Если когда-то сорвалась сверка платежей, импорт клиентских данных или публикация, именно эта запись помогает восстановить ход выполнения.

У сентябрьского изменения есть три важные границы:

• Для Workflow на Workers Paid, созданного 10 сентября или позже, состояние завершённых и ошибочных экземпляров по умолчанию хранится семь дней.
• Существующий Workflow сохраняет прежние правила хранения. Cloudflare не стала задним числом сокращать срок для ранее созданных Workflow.
• На Workers Free ничего не меняется: три дня остаются и сроком по умолчанию, и пределом.

На платном тарифе состояние по-прежнему можно хранить до 30 дней. Cloudflare снизила значение по умолчанию, но не максимальный срок.

Это различие снимает нестыковку в документации. Страница с тарифами обновлена 21 июля и всё ещё называет 30 дней сроком по умолчанию для Paid. Справочник Workers API обновлён 12 августа и утверждает, что без явной настройки срока действует максимум для аккаунта. Обе страницы появились раньше записи в журнале изменений от 10 сентября.

Ориентируйтесь на более новое и точное правило: семь дней по умолчанию для вновь созданных Paid Workflows. Для существующих Paid Workflows ничего не изменилось, а верхняя граница по-прежнему составляет 30 дней.

Семь дней в Cloudflare Workflows — новый дедлайн для инцидента

Вопрос не в том, кажется ли семь дней коротким сроком. Важно, успевает ли команда узнать о существенном сбое до конца седьмого дня.

Руководитель бэкенд-разработки, отвечающий за обработку платежей или заказов, может узнать о расхождении лишь после сверки со стороны поддержки или финансового отдела. Если к этому моменту экземпляр уже удалён, внешняя запись о транзакции останется, но команда потеряет попытки выполнения шагов, сведения об ошибках и результаты Workflow, по которым можно восстановить путь исполнения.

У SRE есть другая ловушка. Cloudflare позволяет запрашивать метрики Workflows за 31 день, однако это аналитическое окно не равно сроку хранения подробного состояния экземпляра. Метрика покажет, что сбой произошёл. Но она не доказывает, что параметры, результаты, попытки и ошибки старого экземпляра всё ещё доступны.

Здесь работает тот же принцип, что и для инструментов анализа сбоев ИИ-агентов: срок хранения данных должен покрывать задержку между самим сбоем и моментом, когда кто-то понимает его значимость.

Для технического руководителя агентства главная опасность — непоследовательность. Давно работающий клиентский Workflow, созданный до изменения, может сохранить прежнее окно, а его замена, созданная после изменения, незаметно получит семь дней. Код выглядит прежним, но регламент для клиента уже ошибочен.

Отделите дешёвую историю успехов от ценной истории ошибок

Cloudflare неслучайно предлагает две настройки:

• successRetention определяет, сколько хранится состояние после успешного завершения.
• errorRetention определяет срок хранения после завершения с ошибкой или принудительной остановки.

Успешный запуск часто оставляет итог в другой системе: строку заказа, ключ объекта, идентификатор отправленного сообщения или запись о завершённом импорте. Если именно эта система служит источником истины, короткого окна для успешных запусков может хватить на оперативные обращения в поддержку и проверку повторного запуска.

С ошибками всё иначе: ценность представляет сам незавершённый путь. Для расследования могут понадобиться сбойный шаг, предыдущие попытки, входные параметры и промежуточный результат. Если проблема способна проявиться с задержкой, длительное хранение ошибок обосновать проще, чем одинаково долго держать каждый успешный запуск.

Официальный пример к изменению прямо разделяет эти сроки:

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

Это лишь пример, а не универсальная рекомендация. Срок хранения ошибок выбирайте по максимально реалистичной задержке между сбоем, его обнаружением и расследованием. Срок для успешных запусков — по тому, как долго операторам нужна запись Workflow после появления реального результата в системе учёта.

Экономика хранения требует отдельного учёта активного состояния

Cloudflare тарифицирует хранилище Workflows в GB-month. На Workers Paid в тариф включён 1 GB-month, а дополнительный объём стоит $0.20 за GB-month. Показатель рассчитывается как среднее ежедневных пиковых значений за 30-дневный расчётный период.

В общий объём входят выполняющиеся, ожидающие, ошибочные и завершённые экземпляры. Поэтому короткое хранение конечных состояний сокращает объём завершённых запусков, но не убирает состояние задач, которые всё ещё выполняются или находятся в ожидании.

На актуальной странице с тарифами указано, что оплата шагов и хранилища Workflows действует с 10 августа 2026 года. Более раннее июльское уведомление обещало лишь, что тарификация начнётся не раньше этой даты. Текущая страница фиксирует опубликованную дату начала, но всё равно не доказывает, что именно увидит конкретный аккаунт в следующем счёте.

Ниже — намеренно условная модель, а не бенчмарк Cloudflare и не обещание экономии.

Предположим, при стабильном объёме успешные запуски добавляют 1 GB нового сохраняемого состояния в день. Активные, выполняющиеся и ожидающие экземпляры дают ещё 0.5 GB-month в обоих сценариях. Чтобы отдельно оценить срок хранения успешных запусков, исключим из сравнения объём ошибок. Если errorRetention остаётся равным 30 дням, измерьте этот объём и добавьте одинаковую строку истории ошибок с обеих сторон.

Разница в модели составляет $4.60. Именно поэтому исходные данные нужно называть явно. Команда с крошечными результатами шагов может почти ничего не сэкономить. У Workflow с большим объёмом запусков и объёмными результатами строка сохранённых успехов окажется намного крупнее. Новое значение по умолчанию меняет множитель, но счёт определяют размер состояния и частота завершений.

Где проходят честные границы

Максимум для Paid по-прежнему равен тридцати дням. Если клиент, регулятор или ежемесячная сверка способны выявить проблему позже, состояние экземпляра Workflow не может быть единственным архивом. Выгружайте минимально необходимый набор данных в систему с собственной политикой хранения и доступа.

Более длительное окно для ошибок означает и больший объём их состояния. Правильная политика — не «хранить ошибки вечно», а дать достаточно времени на обнаружение и восстановление хода инцидента, после чего оставить компактную постоянную запись: идентификатор экземпляра, версию Workflow, временные метки, статус, очищенное от чувствительных данных сообщение об ошибке и затронутый бизнес-объект.

Короткий срок для успешных запусков тоже требует условия: достоверная запись результата уже должна находиться в другом месте. Если только результат Workflow подтверждает, что действие состоялось, его раннее удаление сокращает одновременно и объём хранилища, и доказательную базу.

Наконец, переопределения на уровне экземпляра способны раздробить политику. Агентство с несколькими путями создания может правильно выставить значение в панели, но оставить один путь вызова, который запросит другой срок. Срок хранения должен проверяться в ревью кода, регламенте и модели затрат, а не только в настройках панели.

Что сделать сейчас

Действуйте уже на этой неделе, если вы создали Paid Workflow 10 сентября или позже, сведения о сбоях могут доходить до ответственного спустя более чем семь дней либо объём завершённого состояния существенно влияет на расходы. Задайте разные сроки для успехов и ошибок.

С оптимизацией можно подождать, если Workflow пока остаётся пилотом с малым объёмом, а его сохранённое состояние укладывается во включённый 1 GB-month. Но политику всё равно стоит задать явно: окно расследования важно, даже когда доплата за хранилище равна нулю.

Изменение значения по умолчанию вас не затрагивает, если Workflow существовал до 10 сентября. Для Workers Free тоже ничего не поменялось: срок по умолчанию и предел остаются равны трём дням. Однако в обоих случаях внешняя запись по-прежнему нужна, если бизнес должен расследовать события за пределами окна платформы.

В понедельник проверьте все пути создания новых Workflows. Явно задайте successRetention и errorRetention, затем смоделируйте безопасный сбой и определите последний день, когда подробное состояние ещё доступно. Внесите эту дату в регламент до того, как проверку устроит первый настоящий инцидент.

Получайте следующие практические разборы изменений платформ в рассылке.