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

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

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

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

Живе демо

Тестовий стенд: test.catcode.com.ua (WordPress 7.1 + WooCommerce 10.7). У меню адмінки — Webhook Watchdog: кнопка «Сканувати зараз», час останнього проходу і журнал інцидентів.

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

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

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

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

Перевірка вебхуків за розкладом — кожні 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, — це абсолютно нормально, і це все одно доказ, що хост піднятий.

Що включено в ліцензії

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

Pro — автоматичне ввімкнення вебхука назад як штатний режим, налаштовуваний захист від «мигання» (скільки разів на добу один вебхук можна відновлювати, 0 = без обмежень) і довше зберігання журналу (до трьох років).

Скільки коштує

Базова версія — безкоштовно. Pro — 990 грн на рік за домен. Тестовий період — 7 днів.

Технічні вимоги

• WordPress 6.2+ (перевірено на 7.1).
• WooCommerce 6.0+ (перевірено на 10.7).
• PHP 7.4+.
• Працює з HPOS (власні таблиці замовлень) і з блоковим кошиком та чекаутом — сумісність оголошена явно.
• Для перевірки ендпоінта потрібні вихідні HTTP-запити з сайту (стандартний WP HTTP API).

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

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

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

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

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

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

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

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

Історія версій

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