Keyword monitoring

When to use Keyword#

Use Keyword when the HTTP response body must contain or must not contain a stable, meaningful text fragment. Good examples include a server-rendered product state, maintenance message, or key page heading.

Keyword monitoring fetches an HTTP response. It is not a full browser, authenticated transaction, or JavaScript execution monitor.

Create the monitor#

1. Open Monitors and click New Monitor.
2. Select Keyword.
3. Enter the page URL.
4. Enter the exact keyword or phrase.
5. Choose Should contain or Should NOT contain.
6. Choose the interval allowed by the plan.
7. Keep Expected HTTP status empty unless a specific status is part of the rule.
8. Create the monitor and inspect the first real result.

Choose a stable keyword#

• Prefer a short text fragment that is present in server-rendered HTML.
• Avoid rapidly changing prices, timestamps, counters, personalized text, or content hidden behind consent/login flows.
• Match the exact spelling and case behavior shown by the fetched page evidence.
• Use a test page you control when validating the monitoring setup.

Cache and response evidence#

The monitor detail may show cache-related headers, response age, body size, ETag, Last-Modified, and final URL evidence. A browser and Watchfox can receive different content because of CDN cache, WordPress cache, cookies, location, user agent, or JavaScript rendering.

Before changing the keyword, compare the actual fetched response and cache evidence. Purging a CDN or page cache may be the correct fix when Watchfox is still receiving an older response.

Response too large#

A too_large result means the response exceeded the current 256 KiB keyword-inspection limit. Watchfox could fetch the response but did not inspect enough content to evaluate the rule safely.

Possible actions:

• Monitor a smaller, more specific page or endpoint.
• Reduce unexpectedly large HTML at the source.
• Use Uptime when availability, not body content, is the real requirement.
• Do not assume the keyword is missing; the rule was not evaluated.

Common mistakes#

• Choosing text rendered only by client-side JavaScript.
• Testing a page that varies by cookie, authentication, language, or geography.
• Using a huge response when a smaller endpoint would answer the same question.
• Treating stale CDN content as a Watchfox scheduler problem.
• Using Keyword as the first Watchfox test before validating basic Uptime.