Most data quality problems are discovered the wrong way round: a stakeholder notices a number that looks off in a Power BI report, and only then does anyone go looking for the bad record sitting three tables upstream. The Numlytics Data Quality Monitor is built to flip that - a governed framework that runs a defined set of data quality checks against your database whenever you trigger them, stores the results, and surfaces them in a live Power BI dashboard, before a stakeholder ever has to ask "does this number look right?"

What Data Quality Monitoring Is

Data Quality Monitoring is built on infrastructure most teams already run - SQL Server and Power BI - and designed from the ground up to speak plain SQL, which means the same pattern works equally well against Oracle, MySQL, and Microsoft Fabric. There's no separate application to install, no external service to license, and no data that leaves your environment. At its core, the framework does four things:

Checks are defined once and stored centrally as SQL queries that return failing records. A run procedure executes every active check when it's triggered and writes the results to a dedicated results table. A small set of purpose-built views transforms those raw results into datasets ready for reporting. Power BI connects to those views, and a dashboard of KPI cards, trend charts, and drill-down tables updates on refresh.

The effect is that data quality stops being a periodic audit exercise and becomes a standing layer that sits underneath every other report and dashboard your organisation relies on - regardless of which database engine that report is ultimately reading from.

Why One-Off Scripts Don't Scale

Most organisations start data quality work the same way: an analyst writes a one-off SQL query to check for nulls, duplicates, or orphaned records, runs it manually when something looks wrong, and moves on. That works for one check on one table. It stops working the moment there are twenty checks across ten tables owned by three different teams, because nothing forces those queries to run consistently, nothing records whether they passed or failed last time, and nothing tells anyone when a new failure appears unless someone remembers to look.

Data Quality Monitoring replaces that ad hoc pattern with a registry model: every check is registered once, with an owner, a severity, and a threshold attached, and the framework takes responsibility for running it on request, recording the outcome, and raising an alert when something breaches its threshold. The analyst's one-off query becomes a governed, auditable, consistently monitored check.

"The goal isn't to write more data quality checks - it's to make sure the checks you already know you need actually get run, get recorded, and get surfaced to the right person the moment they fail."

The Check Registry: A Single Source of Truth

Every check in Data Quality Monitoring lives in a single registry table - the definitive record of what gets checked, how severe a failure is, and exactly what SQL defines a failing record. Each registered check carries:

• A category and sub-category - Completeness, Validity, Referential Integrity, Uniqueness, Timeliness, or Custom - so checks can be grouped and filtered meaningfully rather than existing as an undifferentiated list.
• A severity (Critical, High, Medium, or Low) and a fail threshold - the number of failing rows tolerated before the check is flagged as an actual issue, which prevents low-volume anomalies from triggering the same alert as a genuine data breakdown.
• The check SQL itself, which must return three specific aliased columns identifying the failing record, the field responsible, and a human-readable description of the issue - a deliberate constraint that keeps every check's output consistent enough to feed a single dashboard regardless of which table, business rule, or platform it covers.
• An owner - a named individual with routing information, so there's no ambiguity about who investigates a failure.

On-Demand Execution: You Decide When Checks Run

A single procedure is the engine of the framework. Trigger it - from the Power BI dashboard, from a query tool, or as part of whatever process your own team already uses to control timing - and it works through every active check in the registry, runs each one, counts the failing rows, and writes a result row. Where failures exist, it also captures a snapshot of the failing records themselves, so investigating an issue later doesn't require re-running the original query against data that may have already changed.

Two design choices make this safe to run against production systems. First, checks read data at a non-blocking isolation level, so running a check can't stall transactional workloads on the tables it's inspecting. Second, execution can be targeted - by category, by a single check, or in a debug mode that runs the check logic without writing results - so a specific check can be validated or re-tested without triggering a run of everything in the registry.

Validation: Bad Checks Never Reach Production

A data quality framework is only as trustworthy as the checks feeding it, so Data Quality Monitor validates every check definition before it's allowed to run. When a new check is added or an existing one is modified, two automatic validations fire before the change is accepted: the required output columns must be present and correctly aliased, and the severity value must be one of the framework's four approved levels. A separate validation step compiles the check's SQL against the live schema - without returning any data - specifically to catch syntax errors, references to renamed or dropped tables, and references to columns that no longer exist, all before the check is ever run.

Every change to a check definition is also written to a dedicated audit table, capturing who made the change, when, and what the previous values were - giving data quality itself the same governance discipline typically reserved for the production data it monitors.

Five Views: How Power BI Gets Its Data

Power BI never queries the raw framework tables directly. Instead, it connects to a small set of purpose-built views, each designed for a specific page or visual in the dashboard. This separation matters for two reasons: the underlying tables can evolve without breaking the report, and the views act as a deliberate boundary controlling exactly what data is exposed to the reporting layer.

Inside the Dashboard: KPIs, Drill-Down, and Alerts

The dashboard is built to answer three questions in order: how bad is it right now, is it getting better or worse, and where exactly is the problem. The main page opens with KPI cards - total active checks, current issue count, open Critical and High alerts - alongside a priority-ranked list combining severity, failing-row volume, and how long an issue has been open, so the team knows which of several open issues to work first.

From there, a trends view tracks issue volume by severity over time, and a drill-down page shows the individual failing records behind any check - the exact row, the field responsible, and a copyable version of the check's SQL, ready to paste into a query tool for deeper investigation.

Data Quality Monitoring Across SQL Server, Oracle, MySQL, and Fabric

Every part of this framework - the registry structure, the three-column contract, the severity and threshold model, the validation logic, the dashboard views - is a metadata layer sitting above whatever database actually holds the data. That's a deliberate choice: it means the same pattern that works against a basic SQL Server instance extends without redesign to Oracle, MySQL, and Microsoft Fabric.

This matters most in two common situations. Enterprise applications - ERP, CRM, finance systems - are very often built on Oracle, and a data issue there usually surfaces weeks later during a close or an audit. Point checks directly at the Oracle schema and the same issue is caught in the report the day it happens. And for teams standing up new infrastructure on Microsoft Fabric with a Bronze, Silver, Gold medallion architecture, checks registered at each layer show exactly where a bad number was introduced, instead of only noticing it downstream in Gold.

Getting Started

The typical starting point is registering a handful of high-value checks the ones a team already knows matter, such as negative prices, missing required fields, or orphaned foreign keys and letting the Numlytics Data Quality Monitor registry and dashboard take over from there. From that initial set, the model makes it straightforward to expand coverage table by table, or platform by platform, without re-architecting anything.

If your organisation is running data quality monitoring manually, inconsistently, or not at all - on SQL Server, Oracle, MySQL, or Fabric - and wants a governed way to catch bad data before it reaches a report, speak with a Numlytics data quality consultant.