Text assertions answer narrow questions about a response: is this required phrase present, or is this known error phrase absent? They are more targeted than a full content hash and need stable wording to avoid noise.
Required text
A required-text check passes only when the configured string appears in the response body. Use a stable heading, service name or confirmation phrase that should remain present after normal deployments.
Forbidden text
A forbidden-text check fails when the configured string appears. This can help detect an error banner, maintenance message, debug output or known failure phrase on a page that still returns HTTP 200.
Practical examples
- Require “Checkout” on a checkout page.
- Require “Operational” on a public status response.
- Reject “Database connection error” on a homepage.
- Reject a known maintenance banner after planned work has ended.
Keep assertions narrow
Avoid text that changes with timestamps, prices, personalised greetings, rotating promotions or localisation. If the response is naturally dynamic, select a stable phrase or use a dedicated health endpoint.