Your site returns HTTP 200. Uptime monitor stays silent. But the user sees "Something went wrong" instead of your product catalog. The server "works", the application doesn't.
Keyword monitoring closes this blind spot: it checks not just that the server responds, but that the response contains the correct content. Below are 10 scenarios where keyword checks prevent real problems.
How Keyword Monitoring Works
Positive check: page must contain text "Add to Cart". If text missing — alert.
Negative check: page must not contain text "Error" or "Maintenance". If text found — alert.
Combination: in AtomPing keyword check targets a specific string. For API endpoints use JSON path assertions — check a specific field in JSON response.
Use Case 1: Detecting Error Pages Masked as 200 OK
Many frameworks (Rails, Django, Laravel) return custom error pages with HTTP 200 when exceptions occur. CDN may cache the error and serve it to all users. Uptime monitor sees 200 — all good. User sees "Something went wrong".
Setup: keyword check on homepage. Verify presence of a key element (company name, "Sign In", "Get Started").
Catches: cached error pages, deployment failures, database connection errors, template rendering failures.
Use Case 2: Monitoring Prices on E-commerce
Product price is business-critical. Bug in pricing engine, CSV import error, or race condition updating catalog can list items for $0 or $999,999.
Setup: keyword check on key product page. Verify correct price is present (e.g., "$49.99").
Catches: pricing bugs, catalog sync failures, zero-price errors, currency display issues.
Use Case 3: Deployment Verification
After deploy — quick verification: is the new version actually live? Keyword check for version string or unique element from new release confirms deployment succeeded.
Setup: keyword check on /api/health endpoint, verify version: "2.4.1". Or JSON path assertion $.version = 2.4.1.
Catches: failed deployments, partial rollouts (old version still serving), docker image not updated, CDN serving stale content.
Use Case 4: Defacement Detection
Website defacement — attacker replaces site content. Attacker changes homepage, but server still returns 200 OK. Uptime monitor won't notice.
Setup: keyword check for presence of your brand/logo on key pages. Negative check for suspicious content.
Catches: website defacement, unauthorized content changes, DNS hijacking (redirect to phishing page), compromised CMS.
Use Case 5: Monitoring Third-Party Integrations
Your checkout depends on Stripe widget. Your analytics on Google Tag Manager. If third-party script fails to load, uptime monitor won't see it.
Setup: keyword check for presence of stripe.js or gtm.js in HTML. Or check API endpoint that depends on third-party.
Catches: CDN failures from third parties, breaking changes in partner API, expired API keys, blocked scripts.
Use Case 6: Database Connection Verification
App is running, HTTP server responds, but database is unavailable. Pages return 200 OK with empty content or generic error. Health check endpoint with JSON path assertion is better, but keyword check on empty catalog works too.
Setup: keyword check on catalog page — verify presence of a specific product or category. If catalog empty — text missing → alert.
Catches: database connection failures, read replica lag, empty query results, connection pool exhaustion.
Use Case 7: SSL/TLS Mixed Content Detection
Your site is on HTTPS, but someone added an image over HTTP. Browser blocks mixed content, page looks broken. SSL monitoring checks certificate, not mixed content.
Setup: negative keyword check for http:// in source of critical pages (excluding redirect URLs).
Catches: mixed content after CMS update, hardcoded HTTP URLs in templates, third-party widgets with HTTP resources.
Use Case 8: Monitoring Compliance Banners
GDPR cookie banner, terms of service footer, legal disclaimers — regulatory requirements that must be on every page. If banner disappears after deploy — legal consequences.
Setup: keyword check for presence of "Cookie Policy" or "Privacy" in footer of key pages.
Catches: accidental deletion of compliance elements during redesign, broken cookie consent scripts, template errors.
Use Case 9: API Response Validation
API endpoint returns 200 OK, but payload is empty JSON or contains {"error": "unauthorized"}. Standard HTTP check won't catch this.
Setup: AtomPing HTTP check with JSON path assertion. Example: $.data.items exists — verify API returns data, not empty response.
Catches: empty responses, auth token expiry, schema changes, null pointer errors masked as 200 OK.
Use Case 10: Monitoring Competitors and Partners
Keyword monitoring on external sites — legitimate use case. Track partner API availability, monitor competitor prices, verify your product in distributor catalog.
Setup: keyword check on partner page — verify presence of your brand or product.
Catches: de-listing of your product, partner API outages, competitor price changes, marketplace listing availability.
Setup in AtomPing
1. Create Keyword monitor: select URL and text to check
2. Specify type: "contains" (text must be present) or "not contains" (text must be absent)
3. For API endpoints: use HTTP check with JSON path assertions — verify specific fields in JSON
4. Interval: 30 seconds on Free plan
5. Quorum confirmation prevents false positives (CDN returned stale content to one region)
Related Articles
API Monitoring Guide — JSON path assertions for API endpoints
Health Check Endpoint Design — designing /health endpoints
SSL Certificate Monitoring — certificate monitoring
10 Causes of Downtime — typical failure modes
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.