> ## 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.

# Alert Management

> How to manage the alert lifecycle in Prizm — alert states, resolution, issue linkage, and suppression during maintenance windows.

<script type="application/ld+json">
  {`{
            "@context": "https://schema.org",
            "@type": "TechArticle",
            "headline": "Alert Management",
            "description": "How to manage the alert lifecycle in Prizm - alert states, resolution, issue linkage, and suppression during maintenance windows.",
            "url": "https://docs.dqlabs.ai/architecture/alerts/management",
            "publisher": {
              "@type": "Organization",
              "name": "DQLabs Inc",
              "logo": "https://media.brand.dev/332adc35-5bc4-4d2b-bf78-256aa4a5e414.svg"
            }
            }`}
</script>

After an alert fires, two things need to happen: the alert itself needs to be tracked through to resolution, and notifications need to be managed so the team isn't flooded with noise. This page covers both — the alert state lifecycle and alert suppression.

***

## Alert states

Prizm uses three alert states:

| State              | Meaning                                                                                               |
| ------------------ | ----------------------------------------------------------------------------------------------------- |
| **Active**         | The metric is currently breaching its threshold. The alert is open and requires attention.            |
| **Mark as Normal** | A user has reviewed the alert and determined it does not require a tracked issue. A note is required. |
| **Resolved**       | The metric has recovered and the alert is closed — automatically by Prizm or manually by a user.      |

<Note>
  **Suppressed is not an alert state.** When an alert is inside a suppression window, it remains **Active** but notifications are paused. A note is added to the alert history. See [Suppression](#alert-suppression) below.
</Note>

### Marking an alert as Normal

Use **Mark as Normal** when the alert has been reviewed and no remediation is needed — for example, a known data pattern or an accepted deviation that does not warrant a tracked issue.

1. Open the alert detail page.
2. Click **Mark as Normal**.
3. Enter a note explaining the decision (required).
4. Save. The alert closes with your note recorded in the audit trail.

<Note>
  Mark as Normal is not available for metrics using a manual (Limit) threshold. For those alerts, the only states are Active and Resolved.
</Note>

### Resolving an alert

**Automatic resolution** — When the metric that fired the alert runs again and the result is back within the configured threshold, Prizm automatically resolves the alert and records the resolution timestamp. Auto-resolution fires within one evaluation cycle of the metric recovering.

**Manual resolution** — Open the alert and click **Resolve**. A resolution note is required (minimum 10 characters). The note is stored in the audit trail and visible to other users.

All state transitions are recorded in the audit trail with the acting user, timestamp, and reason.

***

## Issue linkage

An alert can be linked to a Prizm issue to track remediation formally:

| Action                        | How                                                                                   |
| ----------------------------- | ------------------------------------------------------------------------------------- |
| **Create a new issue**        | Prizm pre-fills the issue with the alert's metric, asset, breach value, and timestamp |
| **Link to an existing issue** | Attach the alert to an issue already tracking the same root cause                     |

Once linked:

* The alert and issue link back to each other.
* If Jira or Azure DevOps integration is configured, Prizm issue creation cascades to a Jira ticket or ADO Work Item automatically.
* When the alert resolves (auto or manual), the linked Prizm issue is updated to **Resolved** if not already closed.
* When the linked issue is resolved, the associated alert is updated to **Resolved** — propagation works in both directions.

<Note>
  An alert cannot be in Resolved and Active states simultaneously. The state machine prevents invalid transitions.
</Note>

***

## Alert suppression

Alert suppression pauses **notifications** for a defined window or scope. Metric checks continue to run as normal — threshold breaches are still detected and recorded in the audit log. Only the notifications are paused.

### Suppression modes

|                           | Maintenance window                                  | Global suppress                      |
| ------------------------- | --------------------------------------------------- | ------------------------------------ |
| **Scope**                 | Specific asset, schema, or source                   | Entire organization                  |
| **Trigger**               | Scheduled — recurring or one-time                   | Manual, time-bounded                 |
| **Metric checks run?**    | ✅ Yes                                               | ✅ Yes                                |
| **Breaches recorded?**    | ✅ Yes — in audit log                                | ✅ Yes — in audit log                 |
| **Notifications paused?** | ✅ Yes                                               | ✅ Yes                                |
| **Alert state changes?**  | ❌ No — alert stays Active                           | ❌ No — alert stays Active            |
| **Typical use**           | ETL maintenance, deployments, recurring data delays | Incident response, peak load periods |

### Maintenance windows

A maintenance window suppresses notifications for a specific asset, schema, or source during a scheduled period.

* Scope: **asset**, **schema**, or entire **source connection**
* Schedule: **one-time** (specific start/end) or **recurring** (e.g., every Saturday 02:00–06:00)
* Overlapping windows on the same scope are **merged** — the effective suppression covers the union of all configured windows
* All breaches during the window are still written to the audit log with a suppression note
* When the window ends, alerts re-fire normally if the metric is still breaching

**How to configure a maintenance window:**

<Steps>
  <Step title="Navigate to the asset or source">
    Open the asset, schema, or source connection you want to configure suppression for.
  </Step>

  <Step title="Open Suppression settings">
    Go to **Settings → Alert Suppression** for the asset or source.
  </Step>

  <Step title="Add a maintenance window">
    Click **Add Maintenance Window** and configure scope, schedule type (one-time or recurring), start/end times, and a reason note.
  </Step>

  <Step title="Save">
    Click **Save**. The window is active immediately for the configured schedule.
  </Step>
</Steps>

### Global suppress

Global suppress pauses notifications across the entire organization for a manually defined window. Use during active incidents where suppressing all noise helps the team focus.

<Warning>
  Global suppress affects every metric across the organization. Use maintenance windows for targeted suppression and reserve global suppress for org-wide incidents.
</Warning>

### What suppression does and does not do

|                                   | During suppression          |
| --------------------------------- | --------------------------- |
| Metric checks run                 | ✅ Yes                       |
| Threshold breaches detected       | ✅ Yes                       |
| Breaches recorded in audit log    | ✅ Yes                       |
| Notifications sent                | ❌ No                        |
| Alert state changes to Suppressed | ❌ No — alert remains Active |
| SLA timer pauses                  | ❌ No — SLA continues        |

<Note>
  Suppression is a noise-reduction tool, not a remediation action. Use Issues to track and manage the underlying data quality fix.
</Note>