Синтетичний моніторинг транзакцій
Моніторинг транзакцій сайту від HostTracker відтворює реальний користувацький сценарій - вхід, пошук, додавання в кошик, оформлення замовлення - у реальному браузері з 300+ локацій і сповіщає вас тієї миті, коли крок ламається.
Як виконується перевірка транзакції: від першого кроку до сповіщення
Кожен запуск, від першого переходу до вердикту.
Жодного макрозаписувача, який застаріє. Назвіть кроки - саме ця назва з'явиться в сповіщенні.
checkout · 5 кроків · 3,6 с
0 navigate https://shop.example.com/ 1.4 s 1 type #email "[email protected]" 0.2 s 2 click #add-to-cart 0.9 s 3 waitForNavigation /checkout 1.1 s 4 checkContent "Order summary" present 0.1 s
navigate, click, type, select, checkContent, hover, waitForNavigation, sleep, screenshot і back - кожна зі своїм тайм-аутом і назвою.
Будь-яка помилка в консолі браузера завершує перевірку невдачею, з дозволеним списком до десяти підрядків для галасливого стороннього скрипту.
Створюйте і редагуйте монітори транзакцій через REST, SDKs, Terraform або MCP - з повним набором дій.
ДетальнішеПочніть з одного сценарію, збій якого коштує вам грошей, доведіть його до зеленого статусу, і лише тоді додавайте решту. Один відстежуваний сценарій, якому ви довіряєте, кращий за п’ять налаштованих абияк.
Відкрийте сторінку товару, клікніть "додати в кошик", перевірте, що позначка кошика показує один товар, відкрийте оформлення замовлення, перевірте суму та відображення платіжної форми. Зупиніться за крок до оформлення замовлення - і отримаєте повне покриття без тестових замовлень у вашій базі даних.
Введіть облікові дані виділеного тестового акаунту, надішліть форму, дочекайтеся переходу, а потім перевірте текст, що з’являється лише за реальної сесії. Це найцінніший сценарій для більшості застосунків - зламаний вхід означає повний простій, що повертає 200 на кожній сторінці.
Заповніть поля, надішліть форму, перевірте текст подяки. Тихе зламання форми - класичний невидимий збій: нічого не видає помилку, ніщо не сповіщає, а звернення просто перестають надходити, поки хтось не помітить це через кілька тижнів.
Введіть запит, який завжди має щось знаходити, надішліть форму, а потім перевірте, що відомий результат присутній, а текст порожнього стану відсутній. Саме друга перевірка виявляє індекс пошуку, який тихо перестав перебудовуватися.
Пройдіть форму реєстрації до фінального екрана підтвердження й перевірте його, спрямувавши форму на тестову ціль, щоб моніторинг ніколи не створював реальні акаунти. Реєстрація ламається тихо й дорого - ніхто не поскаржиться на реєстрацію, яку не зміг завершити.
Запросіть скидання й перевірте, що з’являється екран підтвердження. Це залежить від вашого поштового конвеєра, черги та сервісу токенів, тож це на диво хороший індикатор для бекенд-проблем, які головна сторінка ніколи не показує.
Сервіс перевірки транзакцій HostTracker гарантує, що всі етапи онлайн-транзакції працюють коректно. Він тестує кожен крок процесу - від додавання товарів у кошик до завершення покупки. Це допомагає знаходити й виправляти проблеми, які могли б завадити клієнтам купити, що покращує клієнтський досвід і зменшує втрачені продажі.
Функція перевірки транзакцій HostTracker всеосяжна й охоплює різні аспекти транзакції в е-комерції. Вона включає відправлення форм, натискання кнопок і переходи між сторінками, щоб відтворити поведінку реальних користувачів. Це перевіряє весь процес покупки, аби переконатися, що він працює справно. Крім того, сервіс надає детальні логи та звіти, які допомагають адміністраторам швидко знаходити й виправляти будь-які проблеми, не заважаючи шляху покупця.
Перевірки транзакцій роблять сайти е-комерції надійнішими та ефективнішими. Вони допомагають підтримувати безперебійну роботу транзакцій, усуваючи проблеми до того, як вони виникнуть. Це означає, що клієнти більш задоволені й більше довіряють сайту. Це також допомагає утримувати клієнтів задоволеними, уникаючи втрачених продажів. Це робить сервіс корисним інструментом для онлайн-магазинів.
Крок за назвою, його знімок екрана та час виконання кожного кроку перед ним.
Результат і сповіщення несуть назву кроку, тож "down" перетворюється на "3 - submit login stopped redirecting".
Зроблений, коли крок зазнає невдачі, поряд із тим, що після останнього кроку - як виглядала сторінка на шляху.
Сайти, сервери, API, сертифікати. Один тип перевірки на сторінку, за всіма - ті самі локації, сповіщення та звіти.
"Я вже довго користуюся цим сервісом моніторингу, і моя щоденна рутина більше не є проблемою. Він тихо стежить за всіма моїми сайтами і дозволяє мені реагувати в ту мить, коли щось йде не так."
Нам довіряють команди з
Кожен розділ відкривається на місці, тож сторінка залишається короткою.
Синтетичний моніторинг означає, що трафік генерується навмисно: замість того щоб чекати, поки відвідувач наштовхнеться на проблему, і сподіватися, що він про неї повідомить, сервіс моніторингу сам проходить ваш сайт за розкладом ззовні вашої мережі. Моніторинг транзакцій - це його багатокрокова форма. Проста синтетична перевірка запитує одну URL-адресу й дивиться на відповідь. Перевірка транзакції відкриває реальний браузер, проходить упорядкований сценарій - відкрити сторінку, увійти, знайти товар, додати в кошик, оформити замовлення - і перевіряє результат на кожній зупинці.
Ця різниця важлива, адже більшість того, що клієнти насправді роблять на сайті, - це послідовність дій, а не перегляд однієї сторінки. Кожна окрема сторінка в оформленні замовлення може повертати HTTP 200, тоді як саме оформлення замовлення зламане: кнопку прибрали під час релізу, форма надсилає дані на ендпоінт, що тепер повертає 404, помилка JavaScript зупиняє майстер налаштування на третьому кроці. Жоден з цих збоїв ніяк не проявляється в коді статусу, тож жоден з них не проявляється у звичайному моніторингу аптайму.
Це не те саме, що моніторинг фінансових транзакцій. У банківській сфері та комплаєнсі "моніторинг транзакцій" означає перевірку платежів на шахрайство й відмивання коштів. Ця сторінка про значення терміна у веб-експлуатації: автоматичне відтворення користувацького сценарію на вашому власному сайті, щоб довести, що він досі працює. HostTracker - це сервіс моніторингу сайтів: він стежить за вашим сценарієм оформлення замовлення, а не за вашою платіжною книгою.
Швидка HTTP-перевірка - правильний інструмент для питання "чи працює сайт". Це один запит, тож і вердикт один: код стану, час відповіді та будь-яке ключове слово чи правило перевірки, яке ви задали для отриманого тіла відповіді. Це велике покриття за дуже малу ціну - і воно закінчується точно там, де закінчується перша відповідь. Усе, що нижче в цій таблиці, стається вже після цього моменту.
| Що насправді зламалося | Швидка HTTP-перевірка | Перевірка транзакції |
|---|---|---|
| Сервер недоступний, збій DNS, відмова TLS-рукостискання | Виявлено | Виявлено |
| Головна сторінка повертає 500 після розгортання | Виявлено | Виявлено |
| Сторінка завантажується, але кнопку "Додати в кошик" прибрали в релізі | Пропущено - HTML і далі повертає 200 | Виявлено - крок кліку не може знайти свій селектор |
| Форма входу надсилає дані на ендпоінт, що тепер повертає 404 | Пропущено - сторінка самої форми в порядку | Виявлено - крок після надсилання так і не досягає сторінки акаунту |
| Виняток JavaScript зупиняє майстер оформлення замовлення на другому кроці | Пропущено - JavaScript ніколи не виконується | Виявлено - браузер виконує скрипт, і перевірка може провалитися на помилках у консолі |
| Сторінка оплати відображає банер помилки замість підтвердження | Пропущено - відображена помилка все одно код 200 | Виявлено - перевірка вмісту на тексті підтвердження провалюється |
| Сесійна кука перестає встановлюватися, тож третій крок повертає на сторінку входу | Пропущено - немає сесії, яку можна втратити | Виявлено - весь сценарій виконується в одній браузерній сесії |
| Сторонній скрипт - чат-віджет, тег-менеджер, платіжний SDK - блокує рендеринг | Пропущено - сторонні ресурси ніколи не завантажуються | Виявлено - браузер завантажує їх так само, як і відвідувач |
| Сценарій працює, але кожен крок тепер триває вісім секунд | Частково - вимірюється лише перша відповідь | Виявлено - кожен крок хронометрується, і крок може перевищити тайм-аут |
Жодна з перевірок не замінює іншу. Чесна рекомендація - запускати обидві: одну HTTP-перевірку щохвилини на тому самому сайті для швидкого виявлення збоїв і перевірку транзакції на одному чи двох сценаріях, які справді приносять дохід. Якщо хочете почати з половини про доступність, почніть з розподіленого моніторингу доступності з 300+ точок і додайте сценарій зверху.
Кожен запуск відкриває реальний, headless-браузер Chromium на одному з чекпоінтів HostTracker і виділяє йому одну браузерну сесію на весь сценарій. Саме ця деталь робить перевірку значущою: куки, токени та стан входу, встановлені на другому кроці, залишаються й на п’ятому - точно так само, як у людини, що клікає вашим сайтом. JavaScript виконується, переходи відбуваються - включно з тими, що запускають ваші власні скрипти, - а сторонні ресурси завантажуються так само, як у браузері відвідувача.
Сценарій послідовний і з негайним припиненням при першому збої. Кроки виконуються в тому порядку, в якому ви їх написали, і перший крок, що провалюється, завершує запуск і стає зафіксованою причиною. Ви ніколи не отримаєте стіну помилок, спричинених однією зламаною кнопкою, - ви отримаєте саме цю зламану кнопку.
Два опційні перемикачі змінюють суворість запуску. Провал на помилці консолі перетворює будь-яку помилку в консолі браузера на провалену перевірку - потужна опція для добре поведеного застосунку, доповнена списком дозволених підрядків (до десяти), щоб відомий шумний сторонній скрипт не кричав "вовк". Пропускати завантаження медіафайлів увімкнено за замовчуванням; вимикайте цю опцію, коли предмет тестування - саме медіа.
Транзакція - це список кроків, і кожен крок - одна дія над сторінкою. Тут немає макрорекордера, який міг би застаріти, - ви будуєте сценарій явно, і саме тому він продовжує працювати, навіть коли ваша маркетингова команда змінює текст на кнопці.
| Дія | Що робить крок |
|---|---|
| navigate | Відкрити URL-адресу. Перший перехід - на власну адресу монітора - додається за вас як нульовий крок. |
| click | Клікнути на елемент, знайдений за CSS-селектором, або за координатою в області перегляду. Ліва, права чи середня кнопка миші, з опційною затримкою утримання. |
| type | Ввести текст у поле, опційно із затримкою між натисканнями клавіш, щоб власні обробники вводу сторінки встигали реагувати. |
| select | Перевірити кількість збігів для селектора: жодного, рівно один, щонайменше один, або будь-яку кількість. Діє на всі збіги, перший, або випадковий. |
| checkContent | Перевірити відображений текст. До десяти ключових слів, будь-яке з них або всі, з урахуванням регістру чи без, наявні або навмисно відсутні, опційно тільки у видимому тексті. |
| hover | Навести курсор на елемент - так ви дістаєтесь меню чи підказки, які з’являються лише при наведенні. |
| waitForNavigation | Дочекатися переходу сторінки, опційно провалюючи крок, якщо перехід не стається вчасно. |
| sleep | Пауза від 1 мілісекунди до 10 секунд, з опційним випадковим розкидом, щоб сценарій не бив по тій самій миті щоразу. |
| screenshot | Зробити знімок сторінки посеред сценарію, щоб збій двома кроками пізніше все одно показав, як сторінка виглядала на шляху туди. |
| back | Повернутися на один запис назад в історії браузера. |
Будь-який крок може супроводжуватись скриншотом і очікуванням переходу після себе, власним перевизначенням тайм-ауту та коротким ім’ям до 19 символів. Називайте свої кроки - це ім’я з’являється в результаті й у сповіщенні, тож "3 - надіслати вхід" - це різниця між сторінкою, що "лежить", і сторінкою, у якої POST-запит входу перестав перенаправляти. У веб-редакторі скриншоти й очікування переходу пропонуються як поведінка після кроку; повний набір дій, включно з наведенням, доступний через API.
id або власний атрибут data-, а не згенеровану назву класу, яка змінюється з наступним білдом.checkContent після кожного значущого переходу - це те, що перетворює послідовність кліків на справжній тест: після входу перевірте текст сторінки акаунту, після оформлення замовлення - текст підтвердження.Якщо хочете спершу перевірити початкову URL-адресу перед побудовою сценарію, запустіть безкоштовну миттєву HTTP-перевірку на ній - без входу в акаунт - або виміряйте, як сторінка завантажується в реальному браузері, за допомогою безкоштовного тесту швидкості сторінки.
Запуск зупиняється на кроці, що провалився, і фіксує побачене. Результат називає крок, класифікує збій - тайм-аут, елемент, який селектор не зміг знайти, перевірка вмісту, що не збіглася, HTTP-помилка, помилка з’єднання, помилка в консолі браузера або неправильно налаштований крок - і зберігає тривалість кожного кроку, URL-адресу, IP та HTTP-статус, на якому завершився кожен перехід, повідомлення консолі браузера й скриншот сторінки в момент збою.
Потім це двічі перевіряють, перш ніж когось розбудити. Одне спостереження про збій не вважається збоєм: перевірка повторюється з інших незалежних локацій, і зміна стану підтверджується лише тоді, коли кворум погоджується. За замовчуванням це мажоритарний вердикт серед максимум семи агентів, мінімум трьох, - тож одна нестабільна локація чи одна тимчасова мережева заминка між дата-центром і вашим хостом не може самотужки згенерувати сповіщення.
Щойно перехід підтверджено, сповіщення надходять із затримкою, яку обрав кожен контакт: одразу, або лише через 3, 5, 15, 30 чи 60 хвилин, або через 3, 6, 12 чи 24 години безперервного збою. Сповіщення надсилаються дев’ятьма каналами, які підтримує HostTracker, - електронна пошта, SMS, голосовий дзвінок, webhook, Slack, веб-пуш і месенджери Telegram, Discord та Viber, - а сповіщення про відновлення надходить, щойно сценарій знову починає завершуватися успішно.
Перевірка транзакції - найпотужніший монітор, який пропонує HostTracker, і водночас той, у якого найбільше реальних обмежень. Знання їх наперед економить пів дня роботи.
Ці два підходи відповідають на різні питання, і команда, яка розуміє цю різницю, перестає очікувати, що один підхід виконає роботу іншого. HostTracker - це сервіс синтетичного моніторингу сайтів: він сам генерує трафік, зі своїх чекпоінтів, за розкладом, який контролюєте ви.
| Синтетичний моніторинг транзакцій | Моніторинг реальних користувачів | |
|---|---|---|
| Хто генерує трафік | Сервіс моніторингу, за фіксованим розкладом | Ваші реальні відвідувачі, коли б вони не з’явилися |
| Працює до появи трафіку | Так - staging-сайт без користувачів усе одно перевіряється | Ні - немає відвідувачів, немає даних |
| Помічає збій о третій ночі | Так - розклад не спить | Не помітить, поки хтось не з’явиться |
| Називає точний крок, що провалився | Так - сценарій детермінований | Рідко - ви бачите симптом, а не послідовність |
| Відображає реальний досвід клієнтів | Ні - це контрольована вибірка | Так - у цьому весь сенс |
| Потребує коду на вашому сайті | Ні - виконується повністю ззовні | Скрипт чи SDK на кожній сторінці |
| Покриває сценарій, який клієнти рідко завершують | Так - ви обираєте, що перевіряти | Ні - рідкісні шляхи лишаються невиміряними |
Якщо наступним вам потрібна саме половина про час завантаження, а не про сценарій, HostTracker також вимірює завантаження реальних сторінок у браузері - див. моніторинг доступу браузера й часу завантаження, - а для машинного еквівалента транзакції перевірка API перевіряє контракт відповіді, а не відображену сторінку. На боці сервера монітор запитів до бази даних часто пояснює, чому сценарій сповільнився в першу чергу.
Моніторинг транзакцій для сайту - це перевірка, яка автоматизує реальний багатокроковий користувацький сценарій - наприклад, заповнення форми, вхід в акаунт, додавання товару в кошик або завершення покупки - і підтверджує, що кожен крок виконується коректно, а вся послідовність дає очікуваний результат. На відміну від простої перевірки, яка лише підтверджує завантаження однієї сторінки, моніторинг транзакцій проходить той самий шлях, яким пішов би реальний відвідувач, - надсилаючи дані й переходячи сторінками послідовно, - а потім звіряє результат із визначеними вами правилами. Це важливо, адже сайт може виглядати цілком справним за будь-якими простими показниками доступності - головна сторінка завантажується, окремі сторінки повертають код 200, - тоді як критичний багатокроковий процес на кшталт оформлення замовлення непомітно ламається на півдорозі. Моніторинг транзакцій HostTracker створений спеціально для того, щоб виявляти саме такий тип збоїв.
Моніторинг транзакцій HostTracker дає змогу автоматизувати й перевіряти широкий спектр взаємодій на сайті, зокрема відправлення форм, натискання кнопок і переходи між сторінками, які разом моделюють те, як реальний користувач рухається вашим сайтом. Це охоплює типові сценарії: проходження реєстрації чи входу, відправлення контактної форми або форми для збору лідів, а також багатокрокові процеси покупки, як-от додавання товарів у кошик і проходження оформлення замовлення. Оскільки перевірка покроково імітує поведінку реального користувача, а не просто завантажує одну сторінку, вона може підтвердити, що кожен етап процесу справді працює й дає очікуваний результат, а не лише те, що задіяні сторінки випадково завантажуються. Це робить її корисною для будь-якого сайту, де зламаний інтерактивний сценарій - а не лише зламана сторінка - коштував би вам лідів, реєстрацій або продажів.
Базовий моніторинг аптайму перевіряє, чи відповідає одна сторінка або точка доступу і чи повертає вона нормальний код стану, що свідчить про доступність сервера, але нічого не каже про те, чи справді працює багатокроковий процес, побудований на його основі. Моніторинг транзакцій йде далі: він автоматизує цілу послідовність кроків - відправлення форми, переходи сторінками, завершення процесу покупки - і перевіряє, що кожен крок виконується успішно, а весь наскрізний процес дає правильний результат. Сайт може проходити кожну перевірку аптайму, тоді як його оформлення замовлення повністю зламане на етапі оплати, адже кожна окрема сторінка й далі нормально завантажується сама по собі; виявити це може лише перевірка, яка справді проходить транзакцію крок за кроком. Для будь-якого сайту, де конверсії залежать від багатокрокового сценарію, моніторинг транзакцій покриває категорію збоїв, яку базові перевірки аптайму просто не здатні побачити.
Так, це один з основних сценаріїв використання моніторингу транзакцій. Перевірки транзакцій HostTracker проходять визначену послідовність кроків - наприклад, додавання товару в кошик, перехід до оформлення замовлення, заповнення обов’язкових полів і досягнення сторінки підтвердження - і перевіряють, що кожен крок виконується як очікується. Це означає, що збій, який виник будь-де в цьому сценарії - чи то зламана кнопка "додати в кошик", помилка валідації форми, чи сторінка оформлення замовлення, що перестала завантажуватися після нещодавнього розгортання, - буде виявлено й зафіксовано в детальних логах із указанням конкретного кроку, на якому стався збій. Швидке виявлення такої проблеми має значення, адже зламаний крок оформлення замовлення напряму коштує продажів і може довго залишатися непоміченим для простих перевірок аптайму, оскільки задіяні окремі сторінки й далі можуть повертати нормальні коди стану.
Коли якийсь крок перевірки транзакції не проходить - форма не відправляється, очікувана сторінка не завантажується або не виконується умова валідації - HostTracker фіксує момент збою і надсилає сповіщення через налаштовані вами канали, тож ви дізнаєтесь не лише про те, що щось зламалося, а й де саме в сценарії це сталося. Разом зі сповіщенням надаються детальні логи та звіти, які дають адміністраторам конкретний крок і результат, потрібні для швидкого розслідування, замість того щоб вручну відтворювати весь сценарій самостійно. Саме ця деталізація на рівні кроку робить моніторинг транзакцій практично корисним для швидкого виправлення проблем: знати, що "оформлення замовлення зламане", значно менш придатно до дій, ніж знати, що збій стається саме на кроці підтвердження оплати після конкретної нещодавньої зміни, - це суттєво звужує коло ймовірних причин.
Ні, хоча багатокрокові сценарії покупки - поширений приклад, моніторинг транзакцій корисний для будь-якого сайту, де має коректно працювати послідовність дій користувача, а не лише завантаження однієї сторінки. Це охоплює сценарії входу та реєстрації для SaaS-застосунків, форми для збору лідів і контактні форми для сервісних компаній, багатосторінкові процеси подання заявок, а також будь-яку навігацію сайтом, де зламане посилання чи невдале відправлення форми на півдорозі завадило б відвідувачу завершити те, заради чого він прийшов. Будь-який інтерактивний процес, у якому втрата користувача на півдорозі має реальну ціну - упущена реєстрація, покинута форма ліда, незавершена заявка, - виграє від того, що саме цей сценарій автоматизовано й регулярно перевіряється, замість того щоб просто вважати, що він і далі працює лише тому, що задіяні сторінки завантажуються без помилок.
Перевірка транзакції виконується з обраним вами інтервалом - від 10 хвилин до 24 годин: 10, 15, 30 і 45 хвилин, потім 1, 2, 4, 6, 12 і 24 години. Мінімальний інтервал вищий за одну хвилину, яку HostTracker пропонує для простих HTTP-перевірок, і це зроблено свідомо: перевірка транзакції запускає реальний браузер, завантажує сторінку разом з її JavaScript і покроково проходить ваш сценарій, а це секунди реальної роботи, а не один запит. Типовий підхід - поєднувати обидва типи: одна хвилина для HTTP- чи ping-перевірки відповідає на питання "чи доступний сайт зараз", а перевірка транзакції кожні 10-15 хвилин відповідає на складніше питання - чи досі завершується оформлення замовлення, вхід чи реєстрація за ним. Таке поєднання виявляє серйозний збій протягом хвилини, а зламаний сценарій - протягом одного циклу перевірки, без запуску браузерної сесії проти вашого застосунку щохвилини.
Ні, і не варто цього робити. Перевірка транзакції відправляє реальні форми на ваш реальний сайт, тож правильне налаштування - це виділений тестовий акаунт, тестовий товар чи SKU, а якщо сценарій доходить до оплати - тестовий режим або sandbox вашого платіжного провайдера, точно як для будь-якого автоматизованого наскрізного тесту. Багато команд зупиняють відстежуваний сценарій за один крок до незворотної дії: доходять до сторінки оплати, перевіряють, що вона відобразилася з правильною сумою, і завершують на цьому. Це все одно підтверджує, що кожен крок до моменту оплати працює, без створення замовлення кожні десять хвилин. Те саме правило стосується сценаріїв реєстрації та збору лідів - спрямуйте сценарій на тестову ціль форми або відфільтровуйте надсилання монітора на своєму боці, щоб трафік моніторингу ніколи не забруднював ваші реальні дані.
Розпочніть безкоштовний тестовий період і стежте за критичними користувацькими сценаріями - входом, пошуком, оформленням замовлення - цілодобово.
Частина інструментів моніторингу сайту HostTracker.