Если обновление заказа или другое фоновое действие WooCommerce задержалось, проверьте очередь Scheduled Actions. В ней важны не только количество задач, но и назначенное время, статус и журнал конкретного действия. Наличие pending-записи ещё не означает сбой: задача может быть запланирована на будущее.

Свяжите жалобу с конкретной задачей

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

Откройте WooCommerce → Status → Scheduled Actions. Документация описывает фильтрацию по статусам, поиск по имени hook, дате или группе и просмотр журналов упавших действий. Найдите подходящую запись и сравните её время с жалобой. Это создаёт проверяемую связь между очередью и конкретным пользовательским сценарием.

Проверьте механизм запуска

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

Не меняйте серверные задания по одному скриншоту pending-очереди. Сначала проверьте, действительно ли время выполнения прошло и появляются ли успешные задачи. Если очередь частично работает, причиной отдельного действия может быть его код или внешняя система, а не общий запуск планировщика.

Не запускайте неизвестную операцию повторно

Прежде чем нажимать Run, выясните назначение задачи и проверьте фактический результат во внешней системе. Для платежа, уведомления или интеграционного запроса повтор может иметь последствия. Ошибка ответа не всегда означает, что принимающая сторона ничего не сделала. Решение о повторе должно учитывать возможность безопасного повторного выполнения.

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

Проверьте восстановление на следующем событии

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

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

Не смешивайте будущие задачи с просроченными в одном счётчике ошибок.