Investigate a low Health Score

Move from a weighted score to the incidents causing it.

Last checked 20 August 2026

A low Health Score means the website has substantial weighted open-incident pressure relative to its enabled monitored page count. It tells you where to look first, but not which change to make.

Confirm what is lowering the score

Find the website on Health Report and select View calculation. Note:

  • enabled monitored pages
  • open Advisory incidents and their weight
  • open Warning incidents and their four-times weight
  • open Critical incidents and their 10-times weight
  • total weighted issues
  • the resulting formula

Start with Critical incidents because each one contributes 10 weighted issues. Review Warnings next. However, do not ignore a large Advisory cluster, especially when many observations share one root cause.

Page count provides scale. One Critical incident produces a score of 50 on a site with 10 enabled pages but 91 on a site with 100. A low score on a small monitored set can therefore result from only one or two issues.

Open the underlying incidents

Open Incidents and filter to the website. The Health Score does not show rule names, affected URLs, expected and actual values, or whether several incidents share a cause.

For each high-weight incident:

  1. Open the incident.
  2. Review its latest evidence and affected URL.
  3. Read any before-and-after difference.
  4. Check whether the same deployment, template, redirect rule, crawler restriction, or infrastructure failure explains other incidents.
  5. Decide whether the observed change is harmful, accepted, or irrelevant.

Look for shared causes before fixing records one at a time. A failed deployment can open availability, title, canonical, analytics, and rendering incidents together. Correcting the deployment may resolve all of them.

Compare the chart with current state

Switch Health Report to Days and inspect recent incident-opening lines. A sudden cluster can help you align the change with a release or outage. Flat opening lines with a low current score usually indicate older incidents that are still open.

Remember that chart lines count openings, while the live gauge counts current open issues. An opening spike can remain in history after every issue recovers. A low gauge can remain when there are no new openings today.

Take the appropriate action

For an actual website problem, fix the source and use Check & Verify where the incident offers it. This runs a relevant recheck so TechDash can observe the corrected state.

Use Mark Resolved when the current observed value is now accepted and should become the reference state. This is appropriate for an intentional change after you have reviewed it. It is not a substitute for fixing a harmful condition.

Use Ignore only when that check is not relevant at the selected URL, website, or global scope. An overly broad ignored-check rule can hide future problems and raise the score by removing issues from consideration, so choose the narrowest appropriate scope.

If the incident recovered automatically, confirm the evidence and history before assuming the root cause is permanently fixed. Intermittent failures can reopen.

Verify the result

After rechecking or resolving:

  1. Confirm the incident state changed as expected.
  2. Review other incidents with the same likely cause.
  3. Return to Health Report.
  4. Allow up to five minutes for the cached report to update.
  5. Open View calculation again to verify the new open counts.

Enabling or disabling monitored pages can also change the formula. Do not add low-value URLs or disable important monitoring just to improve the score. The goal is accurate coverage and resolved problems, not the largest possible number.

If the score remains low, compare the calculation before and after. A remaining Critical incident can outweigh several recoveries, and rounding can sometimes leave the displayed whole-number score unchanged after a small improvement.

Related articles