Choose severity and notification behavior

Set the business importance and interruption behavior for a custom rule.

Last checked 21 August 2026

Every custom check has two separate decisions:

  1. Incident level controls how TechDash classifies and scores a failure.
  2. Notify controls whether a failure or eligible recovery can be sent through configured notification channels.

Do not infer notification behavior from the incident level alone. Unlike ordinary built-in Advisory incidents, an Advisory custom check can send a notification when Send a notification is selected and the relevant channel settings allow delivery.

Choose the incident level

Choose the level from the real effect of this specific requirement:

  • Advisory: useful information or a low-impact deviation that should be visible in TechDash. Examples include an optional page label or a non-urgent deployment marker.
  • Warning: a meaningful requirement has failed and should be investigated soon. Examples include a required analytics ID, legal phrase, or important response-header token.
  • Critical: the failure indicates immediate, high business, compliance, or access risk. Reserve this for assertions whose failure genuinely requires urgent action.

The selected level appears on the resulting Custom check failed incident. It also affects incident ordering, visual treatment, in-app alert tone, and Health Score weighting. Advisory, Warning, and Critical open incidents have progressively larger Health Score weights.

Avoid setting every rule to Critical. Overstated levels make genuinely urgent incidents harder to distinguish and can distort the website's Health Score. Start at the lowest level that accurately reflects the impact, then increase it only when the response process warrants that change.

Choose Send a notification or Incident only

Under Notify, select:

  • Send a notification to make failure transitions eligible for desktop and webhook alerts.
  • Incident only to keep the result and incident in TechDash without sending those notifications.

The custom-check toggle applies even when Incident level is Advisory. Therefore, an Advisory custom check with Send a notification can alert. A Critical custom check with Incident only does not send a desktop or webhook notification from that custom rule.

Notifications are transition-based. TechDash alerts when a previously passing rule fails, subject to configuration. It does not repeatedly alert on every check while the same failure remains open.

If recovery notifications are enabled globally, an eligible custom check can also notify when it starts passing again. The original custom check must be configured to notify.

Channel settings still apply

Send a notification does not bypass other settings. Delivery also depends on the available and enabled channels:

  • Desktop notifications must be enabled globally and for the applicable monitored page.
  • A Slack, Microsoft Teams, or Discord webhook must be configured globally and enabled for the applicable page.
  • The operating system must permit desktop notifications.

For a page custom check, TechDash uses that monitored page's notification toggles. For a website-level resource incident, TechDash uses the homepage notification settings when available, otherwise the first monitored page, with enabled channels as the fallback.

If a custom check opens an incident but no notification arrives, first confirm that its Notify column says Yes. Then inspect the global and page channel settings, send a test notification, and verify operating-system permissions or webhook delivery.

Connect severity to pass and fail evidence

A custom check passes when its configured found or not-found assertion is satisfied. It fails when a required value is absent or a forbidden value is present. The same literal failure can be Advisory, Warning, or Critical because TechDash uses the level you selected rather than inferring business impact from the text.

The failed result identifies the rule and affected page or resource, but literal matching does not explain the cause, validate markup semantics, prove that a script ran, or establish true visual visibility. Consent, personalization, authentication, an intentional migration, a broad scope, or a harmless substring inside longer text can produce a benign failure. Review that evidence before escalating or suppressing it.

The practical repercussion is an open incident with the selected ordering and Health Score weight. Notifications occur only when the rule and channels allow them. After correcting the website or updating a genuinely changed requirement, run the affected page or Site Resources job again. Recovery requires a fresh passing result. Editing severity, turning off notifications, or deleting the rule does not by itself verify recovery.

A safe rollout

For a new rule whose response you have not yet verified:

  1. Choose the accurate incident level.
  2. Start with Incident only.
  3. Save the rule and review its first page or Site Resources result.
  4. Confirm the value is stable across representative checks and review the result in the page checks or Sitewide Checks.
  5. Edit the rule and select Send a notification if interruption is useful.

This sequence avoids noisy alerts from an incorrect target, scope, or literal value while preserving the incident evidence needed to validate the rule.

Related articles