Add a custom check
Create a site-specific found or not-found rule.
Last checked 21 August 2026
Custom checks monitor literal text that is specific to your website. Each rule says where TechDash should look, whether a value should or should not be present, which monitored pages it applies to, and what should happen if the assertion fails.
Before you add the check
Identify the exact value you want to monitor and where TechDash can observe it. A script identifier in HTML, an HTTP response-header value, and customer-facing page copy need different Look in targets.
Use a stable value. Timestamps, session IDs, generated class names, rotating experiment labels, and request-specific tokens can create noisy results. Custom checks use case-insensitive literal substring matching. They do not interpret regular expressions, CSS selectors, XPath, wildcards, or scripts. Leading and trailing whitespace is removed when the rule is saved, and the saved value can contain up to 500 characters.
Add the rule
- Open Websites, then select the website you want to configure.
- Find the Custom Checks card below Monitored Pages.
- Select Add custom check.
- Under Look in, choose Head, Body, Content, Headers, Title, H1, robots.txt, or sitemap.xml.
- If you chose a page target, use Scope to select Sitewide or This page. For This page, select a monitored URL under Page. The resource targets always run sitewide.
- Under Match, select Is found when the value is required, or Isn’t found when the value must be absent.
- Enter the literal text under Value.
- Choose an Incident level: Advisory, Warning, or Critical.
- Under Notify, choose Send a notification or Incident only.
- Select Save check.
The dialog does not ask for a separate rule name. In the Custom Checks table, TechDash identifies the rule from its target, direction, and value, such as Title contains "Pricing".
What happens after saving
Saving a This page rule queues that monitored URL for a check. Saving a robots.txt or sitemap.xml rule queues Site Resources. A new sitewide page rule waits for each monitored URL's next scheduled or manual run, so its first results may arrive at different times.
When the assertion passes, its check result is Good. When it fails, TechDash opens Custom check failed at the incident level you selected. A failing Is found rule means the value was missing. A failing Isn’t found rule means the forbidden value was present.
Notification delivery is separate from incident creation. Send a notification makes the transition eligible for desktop and webhook delivery, including for an Advisory custom check. The relevant global channel and per-page channel settings must also allow delivery. Incident only keeps the result and incident in TechDash without sending those alerts.
After saving, review the first completed result before relying on it for an urgent alert. If the result is surprising, confirm the selected target, scope, matching direction, and exact response that TechDash received.
Worked example: protect the checkout support message
Suppose every checkout page must contain the customer-facing sentence Need help? Call 020 7946 0123. The message matters because customers need a way to get help if payment fails.
Configure the rule like this:
- Look in: Content
- Scope: This page
- Page: the monitored checkout URL
- Match: Is found
- Value:
Need help? Call 020 7946 0123 - Incident level: Warning
- Notify: Send a notification
A pass means that the case-insensitive literal substring occurs in TechDash's filtered rendered body text for that URL. It does not prove that the phone number is clickable, prominent, or visible in every browser state. Content also has filtered-content limitations: it excludes text whose immediate parent is hidden with display: none or visibility: hidden, but can still include text hidden by an ancestor, opacity, offscreen positioning, or other techniques.
For a deliberate test, temporarily change the rule value to Need help? Call 0000. Select Save changes, then find the checkout page in Monitored Pages and select Run now. The check should fail because that literal text is absent. Change the value back after confirming the workflow. A real failure would be a deployment that removes or changes the support sentence.
The failed result appears with that page's check results. TechDash also opens a Custom check failed incident at Warning level, where you can review the affected URL and result evidence. Because Notify is Send a notification, the transition is eligible for allowed desktop and webhook notifications. It may still be quiet if the relevant global or page channel is disabled.
A benign failure can occur when a consent choice, personalization rule, authentication response, or incomplete render changes the captured content. Verify the final URL, HTTP result, selected target, and current rendered response before changing the rule. Do not dismiss a genuine missing support message as benign merely because another browser still has an older cached page.
To verify recovery, restore the required sentence on the checkout page, then select Run now again. A Good result means the configured substring is present in the new snapshot. The incident recovers after the fresh passing evaluation; recovery notifications depend on the notification settings for recovered checks.