WP-Cron и Action Scheduler в WooCommerce: как не терять фоновые задачи

WP-Cron и Action Scheduler в WooCommerce отвечают за большую часть фоновой работы магазина. Пока всё работает, владелец сайта почти не замечает эту инфраструктуру. Но когда очередь перестаёт обрабатываться вовремя, симптомы появляются сразу в нескольких местах: задерживаются письма, webhooks, импорты, синхронизации, очистка сессий, продления подписок и другие автоматические процессы.

Главная ошибка при диагностике — считать WP-Cron и Action Scheduler одним и тем же механизмом. WP-Cron предоставляет WordPress способ запускать задачи по расписанию, а Action Scheduler — отдельную очередь фоновых действий, которую активно используют WooCommerce и расширения. Проблема может находиться на любом из уровней: cron не запускается, очередь перегружена, конкретное действие падает, внешний API отвечает ошибкой или задача слишком тяжёлая для текущего сервера.

Как работает WP-Cron

Официальная документация WordPress объясняет важное отличие WP-Cron от системного cron: WordPress проверяет запланированные события при обращениях к сайту. Если трафика нет, задача, назначенная на конкретное время, может фактически выполниться позже — при следующем подходящем запуске. Подробнее это описано в WordPress Plugin Handbook.

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

Зачем WooCommerce использует Action Scheduler

Action Scheduler — библиотека для обработки фоновых задач с очередью, статусами и историей выполнения. Она позволяет плагину не выполнять тяжёлую операцию прямо внутри запроса пользователя, а поставить действие в очередь и обработать его позже.

Такой подход нужен, когда операция может занять время или должна повторяться: отправка данных, обработка webhook, массовые обновления, продления подписок, фоновые импорты и другие процессы. Документация проекта доступна на actionscheduler.org.

Типичные признаки проблемы

• в WooCommerce появляются просроченные scheduled actions;
• одни и те же действия многократно завершаются со статусом failed;
• очередь pending растёт быстрее, чем обрабатывается;
• письма и webhooks уходят с заметной задержкой;
• задачи работают только после открытия сайта или wp-admin;
• интеграция периодически «догоняет» накопившиеся операции пачкой;
• после обновления плагина появляется много однотипных фоновых ошибок.

Сам по себе большой список completed actions не означает неисправность. Для диагностики важнее возраст pending-задач, повторяемость failed-задач, их hook/group и конкретные сообщения в логах.

Сначала проверьте, запускается ли WordPress cron

Если WP-Cron отключён через DISABLE_WP_CRON, но системный планировщик не настроен, фоновые задачи могут практически остановиться. Если WP-Cron не отключён, но сайт получает мало запросов, выполнение может быть нерегулярным.

WordPress официально описывает вариант, когда встроенный запуск отключают и вызывают cron через системный планировщик. Это особенно полезно там, где задачи должны стартовать предсказуемо. Руководство есть в разделе Hooking WP-Cron Into the System Task Scheduler.

Системный cron не должен запускаться каждую секунду

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

Важно не просто добавить строку в crontab, а проверить, что команда действительно выполняется нужным PHP-пользователем, видит правильную версию PHP, не упирается в timeout и не блокируется конфигурацией сервера.

WP-CLI удобнее HTTP-вызова для серверной диагностики

Если на сервере доступен WP-CLI, им можно смотреть и запускать cron-события без браузера. Это удобно для диагностики и автоматизации. Команды WordPress документированы в разделе wp cron.

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

Как читать Scheduled Actions

В WooCommerce список Scheduled Actions позволяет увидеть hook, статус, дату запуска, группу и журнал выполнения. Для диагностики полезно разделить проблемы на четыре группы.

1. Pending давно просрочены. Вероятна проблема с запуском очереди или производительностью.
2. Failed с одинаковой ошибкой. Cron работает, но конкретный callback не может выполниться.
3. In-progress зависли надолго. Возможен аварийный обрыв PHP-процесса, timeout или блокировка.
4. Очередь постоянно растёт. Скорость создания задач выше скорости обработки либо один тип задач генерируется неконтролируемо.

Почему нельзя просто удалить всю очередь

Массовое удаление scheduled actions без понимания назначения может убрать реальные бизнес-операции. В очереди могут находиться действия оплаты, подписок, отправки данных и синхронизации. Перед очисткой нужно определить источник hook, проверить документацию плагина и понять, может ли задача быть безопасно пересоздана.

Особенно осторожно нужно работать с магазинами, где используются подписки WooCommerce: renewal-сценарии зависят от фоновых задач и требуют проверки всей цепочки.

Когда проблема не в cron

Если Action Scheduler регулярно запускает действие, но оно каждый раз падает, ускорение cron ничего не исправит. Нужно открыть ошибку конкретной задачи и проверить код, запрос к API, ответ внешнего сервиса, права доступа и данные.

Типичный пример — webhook отправляется вовремя, но внешний API отвечает 401 или 429. Здесь очередь работает правильно: она лишь фиксирует неуспешный результат. Исправлять нужно авторизацию, лимиты или retry-логику интеграции.

Что проверить на production-сайте

Как я настраиваю стабильную схему

На рабочем WooCommerce-проекте я сначала фиксирую текущую картину: типы задач, возраст очереди, частоту ошибок и реальную загрузку сервера. Затем отдельно проверяю механизм запуска cron и отдельно — проблемные callbacks.

Если магазину нужен предсказуемый запуск, настраиваю системный cron и проверяю его фактическое выполнение. После этого разбираю failed/pending actions, устраняю причины повторных ошибок и контролирую, что очередь начинает уменьшаться без потери нужных операций.

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

Что считать результатом

Цель настройки — не «нулевая очередь». У нормального магазина фоновые задачи постоянно появляются и завершаются. Результат — когда просроченные действия не накапливаются, повторные ошибки объяснимы, критичные процессы выполняются в ожидаемом интервале, а новые сбои видны по логам.

Если в WooCommerce накопились scheduled actions, задерживаются письма или интеграции, можно прислать описание проблемы. Проверю WP-Cron, Action Scheduler и конкретные зависшие hooks, чтобы исправлять причину, а не просто очищать очередь.