Ваш сайт возвращает HTTP 200. Uptime monitor молчит. Но пользователь видит «Something went wrong» вместо каталога товаров. Сервер «работает», приложение — нет.
Keyword monitoring закрывает эту слепую зону: он проверяет не только что сервер отвечает, но и что ответ содержит правильный контент. Ниже — 10 сценариев, где keyword check предотвращает реальные проблемы.
Как работает keyword monitoring
Positive check: страница должна содержать текст «Add to Cart». Если текст отсутствует — alert.
Negative check: страница не должна содержать текст «Error» или «Maintenance». Если текст найден — alert.
Комбинация: в AtomPing keyword check настраивается на конкретную строку. Для API endpoints используйте JSON path assertions — проверка конкретного поля в JSON-ответе.
Use Case 1: Обнаружение error pages, замаскированных под 200 OK
Многие фреймворки (Rails, Django, Laravel) при необработанных исключениях возвращают custom error page с HTTP 200. CDN может закешировать ошибку и отдавать её всем пользователям. Uptime monitor видит 200 — всё хорошо. Пользователь видит «Something went wrong».
Настройка: keyword check на homepage. Проверяем наличие ключевого элемента (название компании, «Sign In», «Get Started»).
Что ловит: cached error pages, deployment failures, database connection errors, template rendering failures.
Use Case 2: Мониторинг цен на e-commerce
Цена товара — критичный элемент. Баг в pricing engine, ошибка в CSV-импорте, или race condition при обновлении каталога могут выставить товар за $0 или $999,999.
Настройка: keyword check на страницу ключевого товара. Проверяем наличие правильной цены (например, «$49.99»).
Что ловит: pricing bugs, catalog sync failures, zero-price errors, currency display issues.
Use Case 3: Верификация deployment
После деплоя — быстрая проверка: новая версия действительно выкачена? Keyword check на version string или уникальный элемент нового релиза подтверждает, что deployment прошёл успешно.
Настройка: keyword check на /api/health endpoint, проверяем version: "2.4.1". Или JSON path assertion $.version = 2.4.1.
Что ловит: failed deployments, partial rollouts (old version still serving), docker image not updated, CDN serving stale content.
Use Case 4: Defacement detection
Website defacement — замена контента сайта злоумышленником. Атакующий меняет homepage, но сервер продолжает отвечать 200 OK. Uptime monitor не заметит.
Настройка: keyword check на наличие вашего бренда/логотипа на ключевых страницах. Negative check на подозрительный контент.
Что ловит: website defacement, unauthorized content changes, DNS hijacking (redirect to phishing page), compromised CMS.
Use Case 5: Мониторинг third-party integrations
Ваш checkout зависит от Stripe widget. Ваша аналитика — от Google Tag Manager. Если third-party скрипт не загружается, ваш uptime monitor этого не увидит.
Настройка: keyword check на наличие stripe.js или gtm.js в HTML. Или проверка API endpoint, который зависит от third-party.
Что ловит: CDN failures у third-party, breaking changes в API партнёра, expired API keys, blocked scripts.
Use Case 6: Database connection verification
Приложение запущено, HTTP server отвечает, но база данных недоступна. Страницы возвращают 200 OK с пустым контентом или generic error. Health check endpoint с JSON path assertion — надёжнее, но keyword check на пустой каталог тоже работает.
Настройка: keyword check на каталог — проверяем наличие конкретного товара или категории. Если каталог пуст — текст отсутствует → alert.
Что ловит: database connection failures, read replica lag, empty query results, connection pool exhaustion.
Use Case 7: SSL/TLS mixed content detection
Ваш сайт на HTTPS, но кто-то добавил картинку по HTTP. Браузер блокирует mixed content, страница выглядит сломанной. SSL мониторинг проверяет сертификат, но не mixed content.
Настройка: negative keyword check на http:// в исходном коде критичных страниц (исключая redirect URLs).
Что ловит: mixed content после обновления CMS, hardcoded HTTP URLs в шаблонах, third-party виджеты с HTTP ресурсами.
Use Case 8: Мониторинг compliance banners
GDPR cookie banner, terms of service footer, legal disclaimers — регуляторные требования, которые должны присутствовать на каждой странице. Если banner пропадает после деплоя — юридические последствия.
Настройка: keyword check на наличие «Cookie Policy» или «Privacy» в footer ключевых страниц.
Что ловит: случайное удаление compliance элементов при редизайне, broken cookie consent scripts, template errors.
Use Case 9: API response validation
API endpoint возвращает 200 OK, но payload — пустой JSON или содержит {"error": "unauthorized"}. Стандартный HTTP check этого не поймает.
Настройка: AtomPing HTTP check с JSON path assertion. Пример: $.data.items exists — проверяем, что API возвращает данные, а не пустой ответ.
Что ловит: empty responses, auth token expiry, schema changes, null pointer errors замаскированные под 200 OK.
Use Case 10: Мониторинг конкурентов и партнёров
Keyword monitoring на чужих сайтах — легитимный инструмент. Отслеживание доступности партнёрского API, мониторинг цен конкурентов, проверка наличия вашего продукта в каталоге дистрибьютора.
Настройка: keyword check на страницу партнёра — проверяем наличие вашего бренда или продукта.
Что ловит: de-listing вашего продукта, партнёрский API outage, изменение цен конкурентов, доступность marketplace listing.
Настройка в AtomPing
1. Создайте Keyword monitor: выберите URL и текст для проверки
2. Укажите тип: «contains» (текст должен присутствовать) или «not contains» (текст не должен присутствовать)
3. Для API endpoints: используйте HTTP check с JSON path assertions — проверяйте конкретные поля в JSON
4. Интервал: 30 секунд на Free плане
5. Quorum confirmation предотвращает ложные срабатывания (CDN returned stale content to one region)
Связанные материалы
API Monitoring Guide — JSON path assertions для API endpoints
Health Check Endpoint Design — проектирование /health endpoints
SSL Certificate Monitoring — мониторинг сертификатов
10 причин downtime — типичные причины падений
FAQ
What is keyword monitoring?
Keyword monitoring checks whether a specific text string appears (or doesn't appear) on a web page. It goes beyond uptime — your server may return HTTP 200, but if the page shows an error message, empty cart, or 'maintenance mode' text instead of actual content, keyword monitoring catches it.
How is keyword monitoring different from uptime monitoring?
Uptime monitoring checks if your server responds with HTTP 200. Keyword monitoring checks if the response contains expected content. A server can return 200 OK with a completely broken page (cached error, empty database response, wrong deployment). Keyword monitoring verifies the content is actually correct.
Should I check for presence or absence of keywords?
Both. Check for presence of expected content ('Add to Cart', 'Welcome', product names) to verify the page works. Check for absence of error indicators ('Error', 'Maintenance', 'Something went wrong', 'undefined') to catch broken states that still return 200 OK.
What keywords should I monitor on my website?
Focus on business-critical content: product prices on e-commerce pages, 'Sign In' on login pages, 'Submit' on checkout pages, your company name on the homepage, specific API response values. Avoid monitoring volatile content (timestamps, session IDs) that changes on every request.
Can keyword monitoring replace content monitoring tools?
For basic checks — yes. Keyword monitoring in AtomPing verifies specific text exists on a page at 30-second intervals. For full content change tracking (detecting any modification to a page), you'd need dedicated tools like Visualping or ChangeTower. Keyword monitoring is a reliability tool, not a content tracking tool.
How does keyword monitoring work with single-page applications (SPAs)?
Standard keyword monitoring checks the initial HTML response, which in SPAs is often an empty shell. For SPAs, monitor your API endpoints instead — check that the JSON response contains expected data fields. AtomPing's HTTP checks with JSON path assertions are designed for exactly this use case.