Вступ
Базовий моніторинг зазвичай перевіряє лише головну сторінку та HTTP-код. Це краще, ніж нічого, але для сайту із заявками цього замало. Головна сторінка може повертати код 200 OK, а форма при цьому зависає на CRM-webhook, SMTP або антиспамі. У звіті все зелене, користувач роздратований, заявки губляться.
Симптоми
Типова проблема: система моніторингу надсилає запит на `/`, отримує швидку відповідь і вважає, що сайт працює. Але реальний сценарій клієнта проходить через форму, валідацію, зовнішній API, електронну пошту, CRM та сторінку подяки. Будь-яка повільна ділянка в цьому ланцюжку не помітна звичайній перевірці uptime.
Що перевіряється
- які сторінки дійсно важливі для заявки
- яка кількість відповідає кінцевій точці форми
- куди надходить заявка після натискання кнопки «submit»
- чи є тайм-аути у CRM/webhook/SMTP
- що бачить користувач у разі помилки зовнішнього сервісу
- Чи перевіряються сторінка подяки та подія конверсії
- чи існує журнал повільних або відхилених відправлень
Процес виправлення
Спочатку вимірюється реальний шлях: відкрити сторінку, надіслати тестову форму, отримати відповідь, перевірити, чи з’явилася заявка в цільовому сервісі. Потім проста перевірка головної сторінки доповнюється перевірками критичних URL-адрес і, де це можливо, синтетичним тестуванням сценарію. Для зовнішніх API задаються зрозумілі тайм-аути, щоб форма не зависала нескінченно.
Нормальний результат
Після налаштування моніторинг показує не лише доступність головної сторінки, а й стан важливих розділів: форми, сторінки подяки, CRM/webhook та розсилки. Помилка має бути помітною ще до того, як про неї повідомить клієнт.
Висновок
«Зелений» моніторинг марний, якщо він перевіряє не той шлях. Для сайту із заявками головне питання не в тому, «чи відкрилася головна сторінка», а в тому, «чи може користувач залишити звернення і чи потрапить воно на обробку».