Alerts: Automatic data drift and quality notifications

Alerts are created automatically when a metric’s condition is breached — for example, when a freshness check finds a table hasn’t updated within its expected window, or a value falls outside its expected range. PRIZM opens an alert and surfaces it on the Alert page, recording the priority of the problem, the actual value versus what was expected, and the percent change between them, so you can quickly assess impact and decide whether to open an issue.

​

Alert priority levels

PRIZM classifies every alert into one of four priority levels, from most to least urgent.

​

Alert table columns

The Alert page lists every alert with the following columns:

​

Filter by context

Alerts filter by the same five metric contexts used everywhere else in PRIZM: All, Structural, Business, Operational, Performance, and Reconciliation — each shown with a live count. In practice, Structural produces by far the highest volume, since every profiled column carries structural metrics.

​

Alert detail page

Clicking into an alert opens its detail view — the same breadcrumb (warehouse → schema → table → metric) and domain/product tags appear across four tabs: Overview, Timeline, Query & Results, and Audit. An Investigate action runs AI-assisted analysis against the alert at any point.

​

Overview

• Key Metric — three quick stats: when the anomaly was First Seen, when it was Last Seen, and how many times it has occurred (No. of Times).
• AI Summary — a generated explanation of what happened (for example, a value dropping sharply from its baseline), tagged with an Anomaly Type (for example, Drop), a Trend (for example, Stable), and the Related Metric.
• Alert Context — the raw evaluation details behind the alert as a field/value table: the failed condition, the observed and expected values, the deviation and sigma, the baseline type (for example, a Static Threshold versus a learned baseline), and the evaluation frequency (for example, “Conditional — when the asset is updated”).
• Impact Analysis — an AI-assessed severity (for example, Medium), which downstream assets are affected and their own criticality, usage signals for the affected asset (usage level, daily queries, unique users), a recommended action (for example, “Notify downstream consumers”), and the specific downstream assets listed alongside their severity.
• Root Cause Analysis — an AI-generated hypothesis for what caused the anomaly, plus a short, numbered list of concrete steps to confirm and remediate it.

​

Timeline

A chart plotting the metric’s actual value over time with breach points marked, and a table of every occurrence — including ones that passed (OK) and ones where notifications were muted.

​

Query & Results

The underlying SQL query PRIZM ran to evaluate the metric, alongside a live preview of the records it returned — so you can see exactly which rows triggered the alert without leaving the page.

​

Audit

A chronological log of actions taken on the alert itself (for example, Create — “User created a new alert”), separate from the underlying asset’s own audit trail.

​

Creating an Issue from an alert

When an alert needs a tracked fix rather than a one-off glance, it becomes an Issue. This happens two ways:

• Automatically — Critical and High priority alerts can generate an issue on their own, with the metric, asset, alert message, and severity pre-populated so no manual data entry is required.
• Manually — from the alert detail page (or from an asset, metric, or alert cluster), a user can trigger Create Issue directly.

Either way, PRIZM checks for an existing open issue on the same asset first and prompts you to link to it instead of creating a duplicate — the same underlying problem often fires more than one related alert on the same asset over time. A single Issue can absorb multiple linked alerts this way (many alerts to one Issue), with whichever alert is most likely to be the root cause attached as the Issue’s main alert. Creating or linking an issue doesn’t silently resolve the alert. The alert stays active and its status simply moves to In Progress once an issue is attached, so nothing disappears from the Alert page just because a ticket now exists for it. Once linked, the alert and its issue stay in sync:

• If the underlying metric is deactivated or deleted, every issue linked to it is automatically closed with a reason.
• If the metric’s threshold changes, any open linked issue is revalidated and its priority is updated to match the alert’s current severity.
• Resolving the issue updates the triggering alert’s state accordingly, if the alert hasn’t already auto-resolved on its own.

Every issue gets a unique, immutable ID (for example, ISU-1) the moment it’s created — the same ID you see in the Issue column back on the Alert page.