Action Scheduler — это система очередей, которую используют WooCommerce и его расширения для фоновых операций: обработки платежей, вебхуков, отправки писем, синхронизации с CRM и службами доставки, обновления статусов заказов и запуска повторяющихся задач.
Когда очередь перестает обрабатываться, заказы могут надолго оставаться в ожидании, вебхуки — не доходить до внешних сервисов, а письма и синхронизации — отправляться с задержкой. Ниже приведена последовательность проверок, которая поможет найти причину без риска массово удалить важные действия.
Как понять, что очередь Action Scheduler зависла
Проблема не всегда означает, что все задачи с истекшим временем выполнения действительно сломаны. Некоторые действия могли быть созданы с задержкой или ожидать завершения предыдущей операции. Поэтому сначала нужно оценить состояние очереди и повторяемость ошибки.
В панели WordPress обычно используется раздел WooCommerce → Статус → Запланированные действия. Здесь можно просматривать действия со статусами pending, in-progress, complete, failed и canceled, а также фильтровать их по hook или группе.
Тревожными признаками являются постоянный рост количества pending, большое число failed с одинаковым hook, действия, запланированные на прошедшее время, и повторное создание одной и той же задачи после каждой попытки запуска.
- Проверяйте не только общее количество действий, но и самые частые значения hook.
- Посмотрите дату создания, запланированное время и последнюю ошибку.
- Сравните состояние очереди через несколько минут: если количество pending не меняется, обработчик может не запускаться.
- Не путайте pending и failed: pending еще ожидает запуска, а failed завершилось с ошибкой.
Проверка очереди через WP-CLI
WP-CLI удобен для сайтов с большим количеством задач, где административная страница загружается медленно или не показывает всю очередь. Команды нужно выполнять из каталога WordPress либо передать путь к установке параметром, если это настроено в вашей среде.
Для первичной проверки достаточно вывести часть действий со статусами pending и failed:
- Найдите hook, который повторяется в большом количестве записей.
- Обратите внимание на время выполнения: прошедшая дата у pending означает, что действие просрочено, но не обязательно повреждено.
- Проверьте, не относятся ли проблемные действия к одному плагину или интеграции.
- Если команда не распознается, проверьте наличие и совместимость команды Action Scheduler для WP-CLI в текущей среде.
wp action-scheduler list --status=pending --per-page=20
wp action-scheduler list --status=failed --per-page=20Как найти первопричину ошибок
Наиболее ценная информация содержится не в самом статусе failed, а в сообщении об ошибке и контексте конкретного hook. Например, ошибка HTTP может указывать на недоступный API, неверный ключ или превышение лимита запросов. Ошибка базы данных — на проблему с таблицами, блокировки или нехватку ресурсов.
Откройте детали нескольких неудачных действий с одинаковым hook и сравните тексты ошибок. Если они идентичны, причина обычно является системной, а не случайной.
Отдельно проверьте журналы WooCommerce и журнал ошибок PHP на сервере. В них могут быть зафиксированы fatal error, тайм-аут, ошибка аутентификации или исключение конкретного плагина. После включения журналирования не оставляйте избыточный режим debug активным без необходимости на рабочем сайте.
- API: проверьте URL, токены, срок действия ключей, SSL-сертификат, лимиты и ответы сервиса.
- Плагин: проверьте его последние обновления, совместимость и не создает ли он одно действие повторно.
- Сервер: проверьте PHP memory limit, максимальное время выполнения, доступность базы данных и нагрузку.
- Интеграции: убедитесь, что endpoint принимает запросы и не блокирует IP-адрес сервера.
- Заказы: не повторяйте платежные действия вручную, пока не выяснено, не была ли транзакция уже принята платежной системой.
Проверка WP-Cron и loopback-запросов
Action Scheduler часто запускается через WP-Cron или внутренний loopback-запрос. Если WP-Cron отключен, его вызовы блокируются хостингом, а сайт не получает посетителей для запуска псевдокрона, очередь может накапливаться даже при отсутствии ошибки в коде.
Проверьте системный cron хостинга, настройки WordPress и результаты Site Health. Важно выяснить, может ли сервер вообще выполнить PHP-процесс и способен ли сайт обратиться к самому себе через HTTP.
Причиной блокировки loopback могут быть Basic Auth на staging-сайте, firewall, WAF, неправильный DNS, проблемы с SSL, ограничения localhost или плагин безопасности. Не отключайте защитные правила навсегда: сначала определите конкретный запрос и при необходимости добавьте безопасное исключение.
- Если WP-Cron намеренно отключен, настройте системный cron вместо возврата к случайным запускам при посещении сайта.
- Проверьте, не запускается ли одновременно несколько независимых cron-процессов.
- На staging и production убедитесь, что cron использует правильный домен и базу данных.
- После исправления проверьте, начали ли новые действия переходить из pending в complete.
Запуск обработки очереди через системный cron
Для стабильного запуска лучше выполнять Action Scheduler на сервере по расписанию, а не полагаться только на открытие страниц в браузере. Конкретный интервал зависит от объема заказов, производительности сервера и плагинов, которые создают действия.
Пример записи для crontab:
- Замените /var/www/site на фактический путь к WordPress.
- Убедитесь, что команда wp доступна пользователю, от имени которого работает cron.
- Сначала запустите команду вручную и проверьте результат, а затем добавляйте ее в расписание.
- Не настраивайте слишком частые параллельные запуски: это может увеличить нагрузку на базу данных и создать конкуренцию между процессами.
*/5 * * * * cd /var/www/site && wp action-scheduler run --quietРучной тестовый запуск
Перед автоматизацией запустите обработчик вручную в контролируемый момент. Если он сразу возвращает ошибку, сначала исправьте ее, а не увеличивайте частоту cron.
- Сделайте резервную копию базы данных перед массовой обработкой на проблемном сайте.
- После запуска повторно проверьте failed и pending.
- Убедитесь, что выполнение не создает дубликаты писем, вебхуков или внешних операций.
wp action-scheduler runЧто делать с действиями failed и pending
Безопасный порядок действий выглядит так: сохранить информацию об ошибке, определить источник hook, исправить проблему с API, cron, плагином или сервером, а затем повторить обработку. После исправления часть действий failed можно запустить повторно, если это поддерживается вашим сценарием и отсутствует риск дублирования операции.
Задачи pending не следует удалять только потому, что их много. Среди них могут быть обновления статуса заказа, уведомления клиентов, платежные вебхуки или синхронизация остатков. Массовое удаление способно оставить заказы в некорректном состоянии.
Удаление или очистка уместны только после проверки того, что действия устарели, дублируются, созданы удаленным плагином или больше не имеют бизнес-ценности. Для критических операций сначала зафиксируйте идентификаторы и проверьте результат во внешней системе.
- Не удаляйте всю очередь одним кликом без резервной копии и анализа.
- Не повторяйте платежные или webhook-действия, если не проверен их фактический статус в стороннем сервисе.
- После отключения проблемного плагина убедитесь, что его старые задачи не остались единственной причиной ошибок.
- Для большой очереди обрабатывайте действия постепенно и контролируйте нагрузку.
Типичные ошибки при диагностике
Самая распространенная ошибка — устранять симптом, а не источник проблемы. Очистка очереди может временно убрать записи, но если плагин продолжает создавать некорректные действия, проблема быстро вернется.
Еще одна ошибка — запускать массовую обработку через административную страницу или браузер. Запрос может прерваться из-за тайм-аута, закрытия вкладки или ограничений PHP. Для больших очередей надежнее использовать серверный запуск с контролируемым cron.
Также не стоит без анализа обновлять, отключать или удалять плагины на production. Сначала сделайте резервную копию, проверьте воспроизведение проблемы на staging и определите, какие действия связаны с расширением.
- Не ориентируйтесь только на общее количество задач.
- Не считайте каждое просроченное действие pending поврежденным.
- Не запускайте несколько тяжелых воркеров параллельно без контроля ресурсов.
- Не игнорируйте повторяющийся hook: он часто прямо указывает на проблемный плагин или интеграцию.
Частые вопросы
Можно ли просто удалить все задачи pending?
Нет. В очереди могут находиться платежи, вебхуки, письма и обновления заказов. Сначала определите hook, проверьте бизнес-последствия и только после этого удаляйте подтвержденно устаревшие или дублирующиеся действия.
Почему у задач pending время выполнения указано в прошлом?
Обработчик мог не запускаться из-за проблем с WP-Cron, loopback, сервером или PHP. Также действие могло быть заблокировано другой ошибкой. Прошедшее время указывает на просрочку, но не доказывает, что запись нужно удалить.
Что означает большое количество failed с одним и тем же hook?
Скорее всего, повторяется одна причина: недоступный API, неверные учетные данные, ошибка плагина, лимит сервера или некорректные данные заказа. Просмотрите детали нескольких действий и журналы.
Достаточно ли один раз запустить wp action-scheduler run?
Один запуск помогает проверить обработчик, но не заменяет постоянный cron. Если WP-Cron или серверное расписание не работает, новые задачи снова начнут накапливаться.
Вывод
Диагностику Action Scheduler стоит начинать со статусов pending и failed, повторяющихся hook, текстов ошибок и журналов. После этого проверяют WP-Cron, loopback, API и плагин, который создает проблемные действия.
Безопасное решение — устранить первопричину, настроить стабильный запуск через системный cron и только затем постепенно обрабатывать или очищать очередь. Такой подход снижает риск пропущенных платежей, дублирующихся вебхуков и некорректных статусов заказов.