Edit or delete a custom check

Change a saved rule or remove it from the website.

Last checked 21 August 2026

Open Websites, select the website, and find the Custom Checks card below Monitored Pages. Each row shows the generated check description, its scope, incident level, notification setting, and the Edit and Delete actions.

The row description is generated from Look in, Match, and Value, for example Headers contains "x-environment: production".

Edit a custom check

  1. Select Edit on the rule.
  2. Change any of the available fields:
    • Look in
    • Scope and Page for page targets
    • Match
    • Value
    • Incident level
    • Notify
  3. Select Save changes.

The saved value is trimmed and can contain up to 500 characters. Matching remains a case-insensitive literal substring search.

Changing Look in can also change the available scope. Head, Body, Content, Headers, Title, and H1 can be Sitewide or This page. robots.txt and sitemap.xml are always sitewide, so choosing either resource target removes any page association from the rule.

Saving an edited This page rule queues the selected monitored URL. Saving an edited resource rule queues Site Resources. An edited sitewide page rule is used on each monitored URL's next scheduled or manual page check.

An edit changes the saved rule rather than creating another row. Future evaluations use the new settings. Existing check-run and alert history can still describe earlier results, so note the edit time when comparing old evidence with the new configuration.

If the rule has an open incident, changing the expected value does not prove the website was fixed. Run the relevant check after saving and review the fresh result. For a scope or target change, test representative pages.

Delete a custom check

  1. Select Delete on the rule.
  2. Review Delete this custom check?. The confirmation identifies the generated rule description and explains that it will stop running on the next check.
  3. Select Delete to remove it, or Cancel to keep it.

Deletion removes the saved rule and prevents future page or site-resource evaluations. It does not remove website text, alter a monitored URL, or change robots.txt or sitemap.xml.

Historical alerts and check runs may remain. Deleting a rule is not the same as correcting the site or marking unrelated incidents resolved.

There is no undo action. If you may need the assertion again, record its target, scope, value, level, and notification setting before deletion.

Choose edit or delete

Edit the rule when the business requirement still exists but its literal value, page, target, incident level, or notification behavior has changed.

Delete the rule when the requirement no longer applies or was created in error. Do not weaken or delete a valid high-impact assertion merely to silence a real website failure. Correct the website, run the check again, and let the result recover when the requirement is still valid.

If a custom check should temporarily remain visible without interrupting anyone, edit Notify to Incident only. If its impact was overstated, adjust Incident level separately.

Worked example: update a retired support number

Suppose a checkout-page rule requires Call 020 7946 0123, but the business replaces that number with Call 020 7946 0456. The requirement still matters because customers need the current support route, so edit the rule instead of deleting it.

Select Edit and configure:

  • Look in: Content
  • Scope: This page
  • Page: the monitored checkout URL
  • Match: Is found
  • Value: Call 020 7946 0456
  • Incident level: Warning
  • Notify: Send a notification

A pass means the new case-insensitive literal substring occurs in TechDash's filtered rendered body text. It does not prove the old number is absent. If both conditions matter, add a separate Isn’t found rule for the retired number.

For a deliberate failure, save the edited rule before the website deployment, then select Run now on the checkout page. The new value should be missing. That result proves the check can detect the transition. A real failure occurs if the deployment leaves the old number in place or removes the support line entirely.

The result appears with the checkout page's checks, and the failed assertion opens Custom check failed at Warning level. With Notify set to Send a notification, the transition is eligible for enabled desktop and webhook delivery. Use Critical only when a missing contact route creates an immediate, documented business, compliance, or access risk. Editing does not rewrite old evidence, so earlier results can still show the former value and settings.

A benign failure can occur if the number is formatted differently, such as 020 7946 0456 without Call, or if consent, authentication, or rendering changes the captured content. Verify the final URL and current snapshot before broadening the substring. Because matching is literal and case-insensitive, punctuation and internal spacing still matter.

Deploy the new number, then select Run now again. A fresh Good result recovers the incident and verifies the new configuration. If the support-number requirement is later withdrawn completely, record the rule details, select Delete, confirm the prompt, and understand that deletion stops future evaluations. It does not create recovery evidence or prove the page was corrected.

Related articles