Cloudflare Workers пропускали и дублировали Cron Triggers: что проверить после сбоя

Если бизнес-задача выполнялась по расписанию Cloudflare Workers, проверьте окно с 00:48 до 04:15 МСК 27 октября: часть Cron Triggers могла запуститься позже, не запуститься вовсе или выполниться больше одного раза. Инцидент уже закрыт, поэтому сейчас важна сверка фактических результатов. Для конкретного проекта пропуски и повторы пока не подтверждены: сначала проверьте их по журналам и бизнес-данным. Массовый повтор без этой сверки может создать дубликаты.

Cloudflare начала расследование 26 октября в 21:48 UTC и сообщила о затронутой части планировщиков Workers. В карточке инцидента перечислены три наблюдаемых варианта: поздний запуск, пропуск и запуск более одного раза. Статус изменён на «устранён» 27 октября в 01:15 UTC. Это сообщение о работе сервиса, а не доказательство ошибки каждого проекта на Workers.

В сообщении от 23 октября Cloudflare уже описывала похожий инцидент с задержанными, пропущенными и повторными Cron Triggers. Повторяемость события — повод проверить не только журнал провайдера, но и то, как сама задача переносит повтор или отсутствие одного запуска.

Cron Trigger — это расписание, которое вызывает обработчик scheduled() в Cloudflare Worker. Он может запускать синхронизацию каталога, подготовку отчёта, очистку временных данных, отправку уведомлений или обращение к внешнему API. Если проект не использует Workers Cron Triggers, этот инцидент не объясняет его пропущенное задание.

Начните с истории конкретного Worker. В документации Cron Triggers Cloudflare указывает, что раздел Cron Events хранит 100 последних вызовов, а Workers Logs даёт более длинную историю. История вызовов показывает работу обработчика, но итог бизнес-операции всё равно нужно сверять в системе, которую он меняет.

1. Для каждого ожидаемого времени найдите соответствующий вызов: своевременный, поздний, отсутствующий или повторный.

2. Сопоставьте вызов с результатом: созданным отчётом, обновлённой записью, отправленным сообщением или подтверждением внешнего API.

3. Для повторов проверьте, не возникли ли две бизнес-операции с одним назначением. Не ограничивайтесь двумя строками в журнале Worker: второй запуск мог завершиться до изменения данных.

4. Для пропусков определите, можно ли безопасно выполнить задачу позже. Используйте исходный период и стабильный идентификатор операции, если контракт системы это допускает.

5. Запишите решение по каждому спорному запуску: результат уже получен, повтор нейтрализован, задача выполнена позже либо пропуск принят осознанно.

Событие ScheduledEvent соответствует запланированному запуску. Справка обработчика scheduled() описывает поле scheduledTime с запланированным временем и метод waitUntil() для регистрации асинхронных задач, результат которых влияет на статус вызова. Эти сведения помогают связать поздний фактический запуск с исходным расписанием, но не заменяют бизнес-идентификатор заказа, отчёта или периода.

Пропущенную выгрузку иногда можно выполнить позже. Повторно отправленное письмо неприятно, а повторное списание денег с покупателя или создание второго заказа уже меняет данные. Поэтому одно действие «запустить всё ещё раз» смешивает разные риски.

Безопасная задача должна распознавать уже обработанную операцию. Для отчёта таким ключом может быть период, для импорта — версия пакета, для события — стабильный event_id. Если задача вызывает webhook, полезен отдельный разбор о том, почему повторная доставка не должна создавать второй заказ. Механизм зависит от системы, но критерий один: повтор с тем же смыслом не создаёт второй бизнес-результат.

На момент подготовки материала Cloudflare помечает инцидент как устранённый. Это не повод считать последствия автоматически исправленными внутри каждого проекта: провайдер восстановил планировщик, а владельцу приложения остаётся подтвердить, что нужные операции за спорное окно выполнены ровно в допустимом количестве.

If a business task was executed via a Cloudflare Workers schedule, check the window from 00:48 to 04:15 MSK on October 27: some Cron Triggers may have started late, failed to start, or run more than once. The incident is already closed, so verifying actual results is now critical. For a specific project, skips and repeats have not yet been confirmed: first verify them against logs and business data. A mass repeat without this verification can create duplicates.

Cloudflare began its investigation on October 26 at 21:48 UTC and reported the affected portion of Workers schedulers. The incident card lists three observed variants: late start, skip, and multiple starts. The status was changed to "resolved" on October 27 at 01:15 UTC. This is a service status update, not proof of an error in every project on Workers.

In a message from October 23, Cloudflare had already described a similar incident involving delayed, skipped, and repeated Cron Triggers. The recurrence of the event is a reason to check not only the provider's logs but also how the task handles a repeat or a missing single run.

A Cron Trigger is a schedule that invokes a handler scheduled() in a Cloudflare Worker. It can trigger catalog synchronization, report preparation, temporary data cleanup, sending notifications, or calls to an external API. If a project does not use Workers Cron Triggers, this incident does not explain its skipped job.

Start with the history of a specific Worker. In the Cron Triggers documentation, Cloudflare states that the Cron Events section stores the 100 most recent invocations, while Workers Logs provides a longer history. The invocation history shows the handler's operation, but the outcome of the business operation must still be verified in the system it modifies.

1. For each expected time, find the corresponding invocation: on-time, late, missing, or repeated.

2. Match the invocation with the result: a generated report, an updated record, a sent message, or an external API confirmation.

3. For duplicates, check whether two business operations with the same purpose were created. Do not rely on just two lines in the Worker log: the second run may have completed before the data changed.

4. For skips, determine whether the task can be safely executed later. Use the original period and a stable operation identifier if the system contract allows it.

5. Record the decision for each disputed run: the result was already obtained, the duplicate was neutralized, the task was executed later, or the skip was accepted consciously.

The event ScheduledEvent corresponds to the scheduled run. The scheduled() handler documentation describes the scheduledTime field with the scheduled time and the waitUntil() method for registering asynchronous tasks whose results affect the call status. These details help link a late actual run to the original schedule, but they do not replace the business identifier for the order, report, or period.

A skipped export can sometimes be performed later. Resending an email is annoying, but recharging a buyer or creating a second order already changes data. Therefore, a single action "run everything again" mixes different risks.

A safe task must recognize already processed operations. For a report, such a key can be a time period; for an import, a package version; for an event, a stable event_id. If the task triggers a webhook, a separate analysis is useful regarding why a retry must not create a second order. The mechanism depends on the system, but the criterion is one: a retry with the same intent must not produce a second business result.

At the time of preparing this material, Cloudflare marked the incident as resolved. This is not a reason to assume consequences are automatically fixed within each project: the provider restored the scheduler, but the application owner must confirm that the required operations were performed exactly within the allowable count during the disputed window.