This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Issues

Check instance health with issues

This page lists all issues raised across monitored SQL Server instances.

An issue is created whenever an instance violates one or more rules defined for that instance. Rules are organized as Policies and Predicates: a Policy is a container, and Predicates are the individual tests that are evaluated.

Evaluation engine

  • The background evaluation engine runs policies on a schedule:
    • Diagnostic policy: checks instance configuration and best-practice enforcement. Runs once per day.
    • Performance policy: evaluates runtime performance predicates. Runs every 5 minutes.
  • If any predicate in a policy fails during evaluation, an issue is created.
  • When a previously failing predicate later succeeds, the corresponding issue is automatically closed.

Issue lifecycle

  • Issues behave like ticketed findings: they describe a problem and include context, severity, and links to the instance and failing predicate.
  • The system avoids duplicate open issues: if an issue is already open for the same predicate/instance, further failing evaluations do not create new issues; the existing issue is kept and updated as needed.

List view and filters

  • The Issues page shows the full set of issues; use the controls at the top of the page to filter the list:
    • Open vs All: show only open issues (default) or include closed issues.
    • Instance filter: select one instance from the dropdown.
    • Text filter: search by text in issue title, description or instance name.
    • Flagged only: show only issues marked for follow-up.
  • Use the filters to focus on current operational problems or to review historical findings.

Selection and bulk actions

  • Next to the filters are controls to Select All or Unselect All issues.
  • Each row has a checkbox; when one or more issues are selected the toolbar shows a “Close Selected” button. Use that button to close all selected issues in a single operation.
  • Bulk close preserves issue metadata and records the closing actor and time.

Grouped view (by predicate)

  • At the top-left of the toolbar a toggle switches the list between the normal individual-issue view and a grouped view organized by predicate.
  • In grouped view each row represents a predicate and shows counts of issues for that predicate. Use this view to quickly spot frequently failing predicates and to prioritize policy-level fixes.
  • Click a grouped row to expand and see the underlying issues or to jump to a predicate detail page for remediation guidance.

At the top of the page there is a Create new issue button. Use this to manually open an issue that is not produced by policy evaluation — for example, to record a task, an ad-hoc investigation, or an operational incident. The button opens the Create new issue page where you can set the title, description, severity, target instance, flags, and assignee. Manually created issues follow the same lifecycle as policy-generated issues and can be closed when the underlying problem is resolved.

Usage tips

  • Start with Open + Flagged to triage urgent problems.
  • Use the instance filter to hand off findings to owners or DBAs responsible for a specific host.
  • Click an issue to view details, suggested remediation, and evaluation history. Closed issues remain available for audit and trend analysis.

Export and settings

  • At the top-right of the page there is an export button that downloads the current list of issues as an Excel file. Use this to share findings with stakeholders who do not use the application or to perform offline analysis.
  • The settings (gear) button opens the Policies page. From there you can view and edit Policies and Predicates or adjust parameters and notification settings for each rule.

Usage tips

  • Start with Open + Flagged to triage urgent problems.
  • Use the instance filter to hand off findings to owners or DBAs responsible for a specific host.
  • Click an issue to view details, suggested remediation, and evaluation history. Closed issues remain available for audit and trend analysis.

List behavior and row layout

  • The issues list uses infinite scrolling to load more rows as you scroll.
  • Each row represents a single issue and contains:
    • Title: typically the predicate name for policy-generated issues. Click the title to open the Issue Detail page.
    • Rule detail: a short explanatory line describing the failing predicate (for example: “free_percent is 11, should be 20”).
    • Instance and object: the target instance and, when applicable, the database or object name referenced by the issue.
  • Right-side controls:
    • Created date: timestamp when the issue was opened.
    • Flag icon: toggle to mark the issue as important for follow-up.
  • Use the row checkbox to select issues for bulk actions (Select All / Unselect All and Close Selected).

1 - Issue Details

Details of an issue

This page shows full context and actions for a single issue.

Top: Title and description

  • Title: the issue title (often the predicate name for policy-generated issues).
  • Description: a short statement of the failing condition. Example: “free_percent is 11, should be 20”.

Metadata

  • Created: timestamp when the issue was opened.
  • Instance: the SQL Server instance the issue refers to.
  • Database / Object: the database or object name when applicable.

Explanation and remediation

  • A concise explanation describes why the issue matters and recommended remediation steps. Include practical suggestions (for example: clear old files, adjust backup/retention policies, increase disk capacity, or change maintenance windows) and links to relevant documentation or runbooks.

Metric chart

  • A time-series chart displays the metric evaluated by the predicate (for example, available disk space) over the selected interval. The chart shows values up to and including the point when the predicate was evaluated so you can see trend leading to the violation.

Policy evaluation details

  • “Show Policy Evaluation Details” reveals the full evaluation record for the predicate: input properties, threshold values, measured value, evaluation timestamp, policy name, predicate id, and any additional diagnostic fields.
  • Use this to verify the exact inputs that produced the issue.

Tags

  • The Tags control lists tags assigned to the issue and lets you add or remove tags for workflow or routing (for example: “ops”, “storage”, “urgent”).

Closing notes

  • Enter free-form notes describing how the issue was investigated or fixed.
  • Notes are stored with the issue for audit and postmortem purposes.

Actions

  • Save: persists tag changes and closing notes without changing issue state.
  • Close issue: manually closes the issue. If the underlying predicate still fails on a subsequent automated evaluation, a new issue will be opened.
  • Exclude: opens a dialog to disable this predicate for the specific instance/database/object/group/tag combination. The dialog also offers the option to close all matching issues for the selected scope. Use exclusions sparingly and document the rationale (ex. test instance).
  • Fix issue: when available, this button schedules an automated remediation job that executes the predefined T-SQL script associated with the predicate. Not all issues support automatic fixes — availability depends on the predicate and the remediation defined for it. The jobs UI shows the script to be run, required permissions, and the scheduled job status. Execution logs and results are recorded with the job.

Behavior and history

  • Closed issues remain available for historic review; use filters on the Issues list to include closed items.

2 - Policies

Policies

This page lists all Policies configured in the system.

Overview

  • Each row shows a single Policy with its name and a short description.
  • Click a Policy name to open the Predicates page, which lists every predicate (rule) contained in that Policy.

Enable / disable control

  • A toggle beside each Policy enables or disables the Policy and all of its predicates in one action.
  • Disabling a Policy prevents its predicates from being evaluated by the background engine and stops new issues from being created by those rules.
  • Existing open issues created by predicates in a disabled Policy remain visible and can be closed manually; they are not automatically removed.

Usage notes

  • Use the list to review which policy groups are active (for example, Diagnostic vs Performance) and to temporarily suspend evaluation during maintenance windows or policy tuning.
  • Click through to Predicates to adjust individual rules, or thresholds.

3 - Predicates

Predicates

This page lists all predicates defined for the selected Policy.

Predicates list

  • Each row represents a single predicate with concise metadata:
    • Name: predicate identifier (click to open predicate detail).
    • Enabled: toggle to enable or disable the predicate evaluation.
    • Notify: toggle to enable or disable notifications for this predicate.

Behavior

  • Disabling a predicate prevents the evaluation engine from running that predicate and stops new issues from being created by it.
  • Disabling notifications suppresses alerting for failures; issues are still created and tracked, but no notifications are sent for those events.

Controls and actions

  • Click the predicate name to go to the predicate details page
  • Use the inline toggles to quickly enable/disable predicates or notifications.

Usage tips

  • Use the Notifications toggle to mute noisy predicates while retaining the audit trail of issues.
  • Disable a predicate only when you are certain the check is irrelevant or will cause false positives; prefer tuning thresholds where possible.

Overrides and defaults

  • Predicates use shared default values for thresholds, enabled state, and other properties. All organizations inherit the same defaults but may override them as needed.
  • Overrides can be applied at two scopes:
    • Global: applies everywhere the predicate is used.
    • Scoped: applies to a specific combination of instance, database, object, group, or tag. For example, an override on a tag affects all instances that have that tag; an override on a specific SQL instance affects only that instance.
  • Changing any predicate property (including disabling it) counts as an override because the predicate’s effective configuration differs from the shared default.
  • Predicates that have overrides are shown beneath the original unmodified predicate. Overrides are highlighted (orange text) to distinguish them from the default predicate rows (green).
  • When an override is scoped to instance/database/object/group/tag, the override row displays the scope information so you can see exactly where the change applies.
  • To remove an override and revert to the default behavior, use the delete icon on the right of the override row. Deleting the override restores the predicate to the shared default values.

Exclude from evaluation via an issue

  • The “Exclude” action available on an Issue creates the same kind of override described above. When you open the Exclude dialog from an Issue you are setting the predicate’s enabled state to off for the scope you select.
  • The dialog presents checkboxes for scope selection: instance, database, object, group, and tag. Selecting one or more scopes creates a scoped override (enabled = off) that prevents the predicate from running for that specific combination.
  • Excluding from an Issue can optionally close all matching open issues for the selected scope; the override itself is recorded and shown under the predicate (highlighted in orange).
  • Exclusions are reversible: delete the override row to restore the default behavior, or edit the override to change its scope or enabled state.

4 - Predicate Details

Predicate Details

This page contains a form to view and edit all properties of a predicate, including scoped overrides and the evaluation expressions used by the background engine.

Scope controls

  • Server Tag: apply this predicate only to servers that have the selected tag.
  • Server Group: limit the predicate to servers belonging to a specific group.
  • Server: target a single SQL instance for this override.
  • Database: restrict the predicate to a particular database.
  • Object: restrict the predicate to a specific object (for example, a file, table, or index).
  • Use the scope controls to create a scoped override; leaving a field empty makes the override less specific (broader).

Editable expressions and fields

  • Evaluation Expression: the boolean expression the engine evaluates. The default is “actual = expected”, but you can change this to any valid expression supported by the engine (for example “actual < expected” or “actual > low AND actual < high”).
  • Expected Expression: the expected value or expression to compare against. This may be a constant (e.g., 20), a computed expression, or one of the available properties of the object being checked.
  • Actual Expression: the expression that yields the measured value to be evaluated (typically the name of a property from the underlying object, e.g., free_percent or file_size_gb).
  • Property Name: the logical name used to identify the property in UIs and reports. It maps the actual expression to a friendly identifier and can be used by other parts of the system to reference this value (for example in charts or exported data).
  • Filter Expression: an optional expression that narrows the set of objects the predicate applies to. Use it to include or exclude specific objects so the check only runs against matching items (for example: database_name = ‘X’ AND file_type = ’log’).

Behavior and helpers

  • Save applies the changes and creates or updates an override for the selected scope. Changing any property (including disabling) counts as an override.