How TechDash establishes baselines and detects changes

Understand first observations, later comparisons, and incident thresholds.

Last checked 21 August 2026

Many TechDash checks answer "what changed?" rather than "is this value always good?" They need a successful earlier observation before they can make that comparison. This avoids opening incidents for every pre-existing characteristic when you first add a website.

What the first observation does

On the first successful page check, TechDash stores compact signals such as the title, H1, canonical, robots directives, visible-text fingerprint, structured data fingerprint, analytics packages, link counts, image profile, and mobile-rendering measurements. The first non-skipped result for a change rule normally passes with a baseline message, even if the current value would be surprising.

For example, a site added after a deliberate title rewrite does not open Title tag cohort change immediately. A later title change can. The same baseline protection applies to checks such as Canonical changed, Body content changed, Structured data changed, Analytics tags removed, Crawler newly blocked or challenged, and the mobile and template regression checks.

Large comparison content is kept locally. Compact state is stored in the local database, while minified server-returned and browser-rendered HTML are stored as compressed files on this computer. That local evidence lets an incident show readable before-and-after text or markup without uploading the crawl database.

Checks that can fail immediately

Not every check is change-based. Absolute-state checks can report a concrete current failure without waiting for a healthy baseline. Examples include:

  • HTTP errors on monitored pages when the first-hop fetch fails or returns an error status
  • Monitored URL returns a redirect when the monitored URL itself returns 3xx
  • Soft 404 suspected when successful HTML has a not-found title or fewer than 40 words of page copy
  • Empty title tag
  • Duplicate hreflang language code
  • Links to error pages and image destination failures

Website lookups such as certificate validity, expiry, DNS resolution, and domain expiry also use their own absolute-state rules. This is why a first crawl can be quiet for title changes but still report an unavailable page.

Later runs

Later successful runs compare normalized current values with the stored state. A page-check incident is created when a rule transitions from pass to fail. A skipped result does not count as a pass or recovery. Warning and Critical transitions can notify through enabled channels; Advisory findings remain visible in Incidents but do not send a notification.

Some rules have explicit thresholds. Main content disappeared or thinned requires a previous count of at least 80 words and a fall below 35% of that count. Unusual external link growth requires at least 20 links from an empty baseline, or later growth to at least three times the previous count or 20 more links. Mobile horizontal overflow regression requires a move from no more than 10 pixels of overflow to more than 10 pixels.

Other checks run after all enabled monitored pages have current snapshots. These site-wide checks build relationships across the monitored set for duplicate titles and H1s, orphan pages, inbound link loss, hreflang reciprocity, and similar portfolio patterns. Their evidence is limited to the monitored set, not every URL on the website.

Why a comparison may be skipped

A change check cannot produce trustworthy evidence on every run. Most browser and HTML checks are skipped when the first hop is unavailable or redirects, the response is not HTML, the crawler is challenged, or the individual check is disabled for that page. HTTP error and redirect gates always run. When normal HTML returns again, the next successful observation can resume comparisons.

Recovery and reopening

A later passing result closes an open issue. TechDash sends a recovery notification only when recovery notifications are enabled and the incident level is otherwise notifiable. Mark Resolved is different: it records that you accepted the current observed value. The issue stays suppressed while that value remains the same, but it can reopen when the evidence changes.

If a change looks wrong, first confirm that the latest run was successful and compare the previous and current evidence. Fix the source template, content, headers, or deployment, then use Check & Verify. If the change was intentional, Mark Resolved or Ignore can be more appropriate than changing the site.

Related articles