Choose found or not-found matching

Decide whether the value must exist or must be absent.

Last checked 21 August 2026

The Match control defines which state counts as success. Select Is found for a value that must be present. Select Isn’t found for a value that must be absent.

Require a value with Is found

An Is found rule passes when the saved value occurs anywhere in the selected Look in target. It fails when TechDash cannot find that value.

Use it for requirements such as:

An analytics property ID must appear in Head.
A legal phrase must appear in rendered Content.
A cache policy token must appear in Headers.
A product category phrase must appear in Title.
A Sitemap: declaration must appear in robots.txt.

For example, a rule with Look in set to Title, Match set to Is found, and Value set to Pricing passes for a title of Pricing plans | Example. It fails for Plans | Example.

Forbid a value with Isn’t found

An Isn’t found rule passes when the saved value is absent from the selected target. It fails as soon as that literal substring is present.

Use it for requirements such as:

A staging hostname must not appear in Body markup.
A fallback heading must not appear in H1.
A development response-header token must not reach production.
A disallowed path must not appear in the fetched sitemap file.

For example, an Isn’t found rule for staging.example.com in Body fails if that hostname appears anywhere inside the rendered body markup, including an element that is not visible to a visitor.

Understand literal matching

Matching is case-insensitive. A saved value of pricing matches Pricing, PRICING, and the pricing part of a longer string. It is also a substring search, not a whole-word or whole-field comparison. A value of stage would match both stage and stages, so choose enough surrounding text to make the assertion specific.

TechDash trims whitespace from the beginning and end of the saved value. Whitespace inside the value remains part of the literal search. HTML formatting can therefore matter. Text that looks adjacent on screen may be separated by tags or whitespace in Head or Body, while Content uses extracted rendered body text.

The feature does not support regular expressions, wildcards, CSS selectors, XPath, or alternatives such as foo OR bar. Create separate rules if distinct values must be monitored, and remember that each rule can open its own incident.

Interpret a failure correctly

The result is always relative to both the selected target and the response TechDash received:

A failed Is found rule means the value was not present in that target.
A failed Isn’t found rule means the value was present in that target.

It does not necessarily prove that the public website is wrong for every visitor. Authentication, consent, personalization, bot protection, the chosen user agent, redirects, or client-side rendering can change the observed response.

Before enabling an urgent notification, save the rule at a lower incident level or with Incident only, run the applicable page or Site Resources check, and inspect the result. If it surprises you, first verify Look in, Scope, Match, and the exact value. Then confirm that the signal is stable in TechDash's rendered or fetched response.

Choose severity and verify recovery

A failed assertion opens Custom check failed. Use Advisory for low-impact information, Warning for a meaningful requirement that needs investigation, and Critical only when this exact failure creates immediate high business, compliance, or access risk. The repercussion inside TechDash is an open incident, changed Health Score weighting, and, when Send a notification and the relevant channels are enabled, an eligible transition alert.

The evidence states the configured assertion and affected page or resource. It does not identify the code or deployment that caused the match, prove visual placement, or interpret the meaning of a substring. A longer valid phrase can contain a forbidden short value, and an intentional migration can make a formerly required value obsolete. Those can be benign findings, but confirm the requirement before changing the rule.

After correcting the page, resource, target, or assertion, run the affected monitored page with Run now. For robots.txt or sitemap.xml, select Check now in Site Resources. Recovery requires a fresh passing evaluation: the required value must be found, or the forbidden value must be absent. If the resource fetch is unavailable and previous text was reused, restore current access and run again before treating the recovery as verified.