> ## Documentation Index > Fetch the complete documentation index at: https://docs.dqlabs.ai/llms.txt > Use this file to discover all available pages before exploring further. # Alerts: Automatic data drift and quality notifications > PRIZM alerts fire automatically when a measure threshold is breached. Each alert carries a severity level, a drift status, and a percent change value. 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. A metric has breached its threshold in a way likely to have an immediate, significant impact on data consumers. Treat Critical alerts as the highest priority. An elevated, time-sensitive risk that hasn't reached Critical yet, but is expected to worsen if left unaddressed. A measurable deviation from baseline worth investigating, but without the immediate downstream impact of a High or Critical alert. A minor deviation, within a broader tolerance. Recorded for visibility so you can spot a pattern before it escalates. ## Alert table columns The Alert page lists every alert with the following columns: | Column | Description | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Alert Message** | A description of what was detected, usually naming the metric and the observed-vs-expected values (for example, `ASSET LEVEL METRIC condition failed — observed 11,999 vs. expected ≥ 0`). | | **Priority** | One of the five levels above. | | **Actual** | The value PRIZM observed when the metric was evaluated. | | **Expected** | The threshold or expected condition the metric was checked against (for example, `>= 0`). | | **Change %** | The percent difference between the actual value and its baseline. This can be very large (for example, `1.200M%`) when the baseline is at or near zero. | | **Marked As** | The alert's current disposition: blank/**Active** until reviewed, **Normal** once a user clicks **Mark as Normal** on the alert detail page (a note is required), or **Resolved** once the alert closes, automatically or manually. See [Alert Management](/architecture/alerts/management) for the full state lifecycle. | | **Issue** | Links to the tracked Issue created from this alert (for example, `ISU-40`), if one has been opened. This can also be used to create a new issue from the alert. | ## 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. Alerts are read-only from the Alert page's list view — you can't resolve one directly there. Open the linked Issue (or create one) to assign, track, and manage a data quality problem through to resolution.