Metric Troubleshooting¶

Common problems when creating and running a Metric check, their causes, and how to resolve them.

Validation Fails When Creating the Check¶

Clicking Validate returns an error instead of a success message.

Cause: The configuration is incomplete or inconsistent. The most common reasons are that neither Min Value nor Max Value is filled in, that Min is greater than Max, or that the filter clause has invalid syntax.

Resolution:

1. Review the error message: it explains what needs attention.
2. Fill in at least one limit, make sure Min is not greater than Max, and check the filter clause. For Percentage Change, enter the limits in percent.

Validation does not confirm that the filter leaves exactly one row. The first Scan does.

The Check Is Not Asserted Because It Resolved to Several Rows¶

Every Scan records the check as Not Asserted, with a message that it resolved to more rows than the expected 1.

Cause: The rows left after the filter clause are more than one. A Metric check follows a single value, so it cannot pick one row out of many.

Resolution: Narrow the filter clause to one row (for example, region = 'EMEA' on a table with one row per region), or create a Computed Table that aggregates the value into a single row and put the check on it. See Exactly One Row.

The Check Is Not Asserted Because It Resolved to 0 Rows¶

The Scan records the check as Not Asserted, with a message that it resolved to 0 rows.

Cause: No row is left to evaluate. Either the filter clause matches nothing, the field is empty on the row it matches, or the Scan was Incremental and the row did not change since the previous Incremental Scan, so the Scan did not read it.

Resolution:

1. Check that the filter clause matches a row whose field holds a value.
2. For a summary row that is updated in place, scan the container with the Full read strategy. See Read Strategies.

The Change Comparison Never Alerts on the First Scan¶

A new Absolute Change or Percentage Change check passes on its first Scan even though the value looks wrong.

Cause: There is no previous measurement yet, so the first Scan of each read strategy only records the value.

Resolution: Nothing to fix: the check starts comparing on the next Scan. If the first value must be bounded too, add an Absolute Value check on the same field.

The Check Compares with an Unexpected Earlier Value¶

The change in the anomaly does not match the value you saw on the last Scan.

Cause: Incremental and Full Scans keep separate histories. A Full Scan compares with the last Full Scan, which can be days older than the last Incremental one, and the reverse.

Resolution: Run the check's Scans with a single read strategy. See Incremental and Full Scans Keep Separate Histories.

Saving a New Field or Comparison Fails¶

The Field input is disabled, or changing the Comparison and clicking Update returns an error saying the check has already been asserted.

Cause: The field and the comparison are locked once a Scan has included the check, because every recorded measurement belongs to them.

Resolution: Create a new Metric check with the field and comparison you want, then archive the old one. The limits and the filter clause of the existing check can still be changed.

Saving or Activating Fails Because Another Check Conflicts¶

Clicking Save, Update, or Activate returns an error saying an existing check conflicts.

Cause: The container already has an Active Metric check with the same field, filter clause, and comparison. Only one is allowed per combination, whatever its limits.

Resolution: Open the check the message names and edit it instead, or give the new check a different filter or comparison. See One Active Check per Field, Filter, and Comparison.