Webhook Watchdog для WooCommerce — сторож вебхуків

WooCommerce веде лічильник невдалих доставок на кожному вебхуку. Після пʼятої поспіль він ставить вебхуку статус disabled — і не каже про це нікому. Ні листа, ні повідомлення в адмінці, ні запису там, куди власник магазину зазирає.

Історія завжди одна й та сама: інтеграція на тому кінці — Printful, CRM, склад, бухгалтерія — просто перестає отримувати замовлення, а магазин дізнається про це за кілька днів від клієнта або з ненадісланої посилки. На екрані вебхуків написано «Вимкнено», і ніде не пояснено ні коли, ні чому, ні скільки разів так уже було.

Цей модуль — та сама відсутня половина.

Як це виглядає для покупця

Ніяк — і це правильно. Модуль не додає нічого на вітрину, не втручається в кошик, чекаут чи листи покупцям і не сповільнює жодної сторінки магазину. Він працює лише в адмінці й за розкладом.

Що отримує адмін

Перевірка вебхуків за розкладом — кожні 15 хвилин, щогодини, двічі на добу або раз на добу, на вибір. Плюс кнопка «Сканувати зараз», коли треба перевірити просто зараз.

Журнал інцидентів — окремий екран зі своєю таблицею: коли знайдено, який вебхук, топік, URL доставки, скільки доставок провалилось, що зроблено і що відповів ендпоінт. Фільтри за результатом: тільки повідомлено, відновлено, ендпоінт лежить, ліміт вичерпано, не вдалося.

Саме журнал відповідає на питання, на яке не відповідає ні WooCommerce, ні панель самої інтеграції: як довго ця інтеграція вже збоїть і як часто.

Лист — один дайджест на скан, а не лист на кожен вебхук. Коли лягає ендпоінт, він забирає з собою всі свої вебхуки одразу, і дванадцять однакових листів о третій ночі вчать фільтрувати відправника, а не лагодити ендпоінт.

Як це працює — крок за кроком

1. За розкладом модуль питає WooCommerce, які вебхуки зараз у статусі disabled (за бажанням — ще й paused).
2. На кожен такий вебхук пишеться інцидент: топік, URL, лічильник невдач, попередній статус.
3. У режимі «тільки повідомити» на цьому все й завершується — стан магазину не змінюється, ви просто дізнаєтесь.
4. У режимі відновлення модуль спершу перевіряє, чи ендпоінт узагалі відповідає: звичайний HEAD, з відкатом на GET, якщо HEAD віддає 405.
5. Якщо відповіді нема або прийшло 5xx — вебхук лишається вимкненим, а в журналі й у листі пишеться точна причина (аж до тексту помилки cURL).
6. Якщо ендпоінт живий — вебхук вмикається назад, і разом зі статусом скидається лічильник невдач.
7. Записи інцидентів старші за заданий строк видаляються самі.

Проба навмисно ніколи не повторює той payload, який не дійшов. Повторно надіслати справжній вебхук замовлення на ендпоінт, стан якого невідомий, — це рівно той шлях, яким склад відвантажує те саме замовлення двічі. Проба відповідає лише на питання «чи хтось узагалі слухає за цією адресою», і саме воно вирішує, чи варто пробувати вмикати.

Будь-яка HTTP-відповідь, включно з 4xx, вважається ознакою життя: ендпоінт, який відхиляє голий GET, але приймає підписаний POST, — це абсолютно нормально, і це все одно доказ, що хост піднятий.

Що під капотом

Власна таблиця інцидентів — рядок на кожен випадок, коли вебхук знайдено вимкненим, з тим, що з ним зробили. Це те, чого немає ні у WooCommerce, ні в панелі інтеграції: історія, за якою видно повторюваність.

Скидання failure_count при відновленні — не косметика. WooCommerce порівнює поточний лічильник із порогом, тож вебхук, увімкнений із лічильником, що лишився на пʼятірці, помирає знову на наступній же невдачі. Саме цю помилку роблять, коли вмикають вебхук руками.

Захист від «мигання» рахує саме відновлення, а не згадки: вебхук, про який десять разів повідомили, нічого з ліміту не витратив. Без цього обмеження вебхук, чий ендпоінт зламаний так, що проба цього не бачить, воскресав би вічно — по пʼять справжніх запитів за раз.

Проходження загорнуте так, що збій усередині не валить чергу завдань WordPress: сторожовий пес, який падає з фаталом, забирає з собою всі інші заплановані задачі магазину.

Модуль не чіпає таблиці замовлень і нічого нікуди не надсилає, крім листа на вашу власну адресу і проби на той URL доставки, який ви самі вказали у WooCommerce.

Як встановити

1. Плагіни → Додати новий → Завантажити плагін → zip → активувати. WooCommerce має бути активним.
2. У меню адмінки зʼявиться Webhook Watchdog.
3. Лишіть режим «тільки повідомити» на кілька днів — щоб побачити, що насправді відбувається у вашому магазині.
4. Після цього вирішуйте, чи вмикати автоматичне відновлення.