Compliance run & history

Help IDs: compliance.tab.run, compliance.run.now

The Run & History tab kicks the backend engine and shows past executions. Results land in HealthCheck.ReportLog for the header and per-metric HealthCheck.MetricLog* tables for row-level detail.

[Image omitted: Run & History tab with a run selected]

Run now

The ▶ Run now button executes HealthCheck.ReportMaster for the current profile with the current Scope settings. The engine:

1. Resolves cascading thresholds from HealthCheck.MetricThreshold for every (server × DB × metric) combination in scope.
2. Loads a HealthCheck.Work job packet with the resolved thresholds plus the newest CollectionExecutionDateTime from Collector.* per row.
3. EXECs each active metric SP.
4. Each SP joins its own Collector.* source (e.g. Collector.Logins for MetricSysadminCount) with dbo.Servers and Work, applies the threshold comparison, writes row-level results to its MetricLog* table, and updates the header counts in ReportLog.
5. Work gets cleared for that ReportExecutionDateTime.

The Compliance UI shows the run's status in the status bar at the bottom of the page. On success the history grid refreshes to include the new execution. On failure the error text appears in the status bar.

Reports never touch remote servers. The engine reads from already-collected data. If your Collector.* data is stale, your report will be stale too — kick a collector refresh first if you need it fresh.

History grid

One flat MinionGrid over HealthCheck.ReportLog filtered to the current profile, one row per (execution × metric). Default grouping is by ReportExecutionDateTime descending — each execution collapses into its own band.

Columns

Fail / Pass pills

The pills tell you at a glance whether a run had any violations.

| Fail = 0, Pass ≥ 0 | Both pills gray/green — the metric passed everywhere | | Fail ≥ 1 | Fail pill turns red with the count — something didn't pass | | Fail = 0, Pass = 0 | Both pills gray — the metric produced no evaluable rows (usually no data in the collector snapshot for this metric's source table) |

Grouping across runs

Drag Metric into the group panel to switch from "runs, then metrics" to "metrics, then runs". This is the fastest way to answer "has this specific metric been failing over time?" — every row of the same metric across every execution stacks together, so a run of red pills jumps out.

Drag SLA in to compare Gold vs Bronze runs. Drag LogTable in to lump per-metric SP types together (all MetricLogSpConfigureSetting rows in one band, etc.).

Per-column search

The auto-filter row above the columns takes plain text — type sysadmin in the Metric column to show only rows for MetricSysadminCount variants. Type a number in Fail to find every run with that many failures.

Reading a run

Expand a run's group header and scan the Fail pills. Red pills are where to look. Every red-pill row corresponds to rows in the metric's log table, e.g. HealthCheck.MetricLogSysadminCount:

SELECT *
FROM HealthCheck.MetricLogSysadminCount
WHERE ReportExecutionDateTime = '<the run timestamp>'
  AND MetricFail = 1;

That gives you the actual InstanceID + SysadminName that failed — the row-level "who" behind the aggregate count.

Example workflows

Compare a metric across the last 30 days

1. Group the grid by Metric (drag the Metric header into the group panel).
2. Expand the group for the metric you care about (e.g. Sysadmin Count).
3. Every past run of that metric stacks together, newest first.
4. A run of red Fail pills says "this has been failing repeatedly".

Find the run where a check started failing

1. Group by Metric.
2. Expand the failing metric's group.
3. Scroll down through descending runs; the first row where Fail flips from 0 back to a red count is roughly when the regression started.
4. Copy that ReportExecutionDateTime and run the SQL above against the MetricLog* table to see which servers went bad.

Audit "what did we grade in that run?"

Every ReportLog row carries the ServiceLevel, Include, Exclude, IncludeDB, and ExcludeDB values that were passed to ReportMaster. Ungroup the grid (drag the group header out of the panel), enable those columns via the column chooser if they're hidden, and you can see exactly what scope produced a given result set.

Common gotchas

• The current shipped HealthCheck.RunReport SP is a stale stub. The Compliance UI intentionally calls HealthCheck.ReportMaster instead. If Run fails with an error about missing tables, double-check that HealthCheck.ReportMaster exists on your repo DB (it does on any Minion Enterprise release that shipped after the engine was named that).
• A Fail count of zero doesn't necessarily mean the metric passed. It might mean the metric had no evaluable rows — e.g. the collector hasn't populated its source table yet. Check the Pass column and the Source column together.
• "Secs" per metric can vary wildly across runs. Metrics that touch large log tables are slower. Don't compare run-time between two profiles unless the underlying data volume is the same.
• Deleting a profile does not delete its ReportLog history. Past runs stay in the log forever. If you recreate a profile with the same name later, its history appears attached to the new profile.
• ReportLog counts are aggregates across every server in scope for that metric. A Fail = 12 doesn't mean 12 rows failed on one server — it might be one row failed on 12 servers. Use the MetricLog* table for the breakout.

Related: Compliance overview, Compliance scope, Compliance backend, Reports.