Decide when to use a custom check

Use a customer-defined rule for site-specific requirements not covered by built-ins.

Last checked 21 August 2026

Use a Custom Check when your website has a specific required or forbidden value that a built-in TechDash check cannot know. A custom check is a direct assertion: TechDash looks for one literal value in one selected signal and passes or fails based on whether that value is present.

Good uses for custom checks

Custom checks work well for requirements that are stable, specific, and observable in a fetched page or supported site file. Examples include:

  • Require a legal disclaimer or brand phrase in visible Content.
  • Require an analytics property ID, script URL, or verification token in Head or Body markup.
  • Require a cache, security, or application token in Headers.
  • Forbid a known fallback phrase in Title or H1.
  • Require a Sitemap: declaration in robots.txt.
  • Require a known URL, host, or XML namespace in the fetched sitemap.xml file.
  • Forbid a staging hostname, test account ID, or development marker from a production template.

Choose Is found for a required value. Choose Isn’t found for a value that must not appear. Matching is a case-insensitive literal substring search, so pricing also matches Pricing plans. TechDash does not support regular expressions, selectors, wildcards, boolean expressions, numeric comparisons, or custom scripts in this feature.

Prefer a built-in check when one exists

Built-in checks understand the behavior they monitor. They can apply availability gates, establish before-and-after baselines, compare URLs, interpret directives, group affected pages, and provide tailored evidence. For example, use the built-in checks for HTTP errors, redirects, canonical behavior, indexability, duplicate titles, sitemap membership, robots blocking, structured data, and analytics coverage.

Do not recreate a built-in rule by searching for a broad word such as noindex in complete HTML. That literal search may find comments, scripts, or unrelated text and does not interpret the directive. A custom check is most useful for your own invariant, not as a replacement parser.

Check whether the value is suitable

Use text that remains stable across normal requests. Avoid timestamps, cache-busting values, generated IDs, personalized names, rotating experiments, and text that only appears for signed-in visitors. If consent state, geography, a WAF, or client-side rendering changes the response, verify that TechDash consistently receives the signal you intend to monitor.

Choose the narrowest accurate Look in target. Content searches rendered body text, while Head and Body search rendered HTML markup. Headers, Title, and H1 search their extracted signals. robots.txt and sitemap.xml use site-resource fetches rather than a monitored page.

Then choose the narrowest accurate scope. This page is appropriate for a requirement on one monitored URL. Sitewide applies a page rule to every monitored URL as each URL runs. Resource rules always apply at website level.

Finally, choose an incident level based on customer or business impact, and decide whether the rule should send notifications. A test rule can start as Advisory with Incident only while you confirm the observed response. Increase the level or enable notifications only after the rule produces dependable results.

Understand the result and impact

A required-value rule passes when the literal value is found and fails when it is missing. A forbidden-value rule passes when the value is absent and fails when it is found. A failure opens Custom check failed at the configured Advisory, Warning, or Critical level. That level affects ordering, Health Score weighting, visual treatment, and whether the incident represents information, prompt investigation, or urgent action. Notification delivery remains controlled separately by Notify and the enabled channels.

Evidence identifies the rule, affected page or resource, and whether the assertion matched. It does not prove why the value changed, whether a matched script executed, or whether matched text was genuinely visible. A failure can be benign when an intentional release changes the value, the scope is too broad, or consent, authentication, personalization, geography, or rendering changes the observed response.

For recovery, correct the page or resource, or edit the rule when the business requirement itself changed. Run the affected page with Run now, or select Check now for a robots.txt or sitemap.xml rule. Confirm a fresh Good result from current evidence. Do not treat editing or deleting the rule as proof that the website recovered.

When a custom check is not enough

A custom check cannot submit a sign-in form, follow a business workflow, count matches, validate XML structure, inspect every file in a sitemap tree, or compare one page with another. It also cannot prove that a script executed successfully just because its markup is present. Use a purpose-built monitor or a built-in TechDash check when the requirement needs those behaviors.

Related articles