> For the complete documentation index, see [llms.txt](https://docs.opendatadiscovery.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.opendatadiscovery.org/developer-guides/api-reference/alerts.md). # Alerts Alerts surface platform-detected and externally-injected issues against catalog entities. The platform's own ingestion pipeline raises alerts for failed jobs, failed data-quality tests, backwards-incompatible schema changes, and distribution anomalies; the inbound AlertManager webhook (last group below) accepts Prometheus-style notifications and routes each one to a data entity by its `entity_oddrn` label. For the alert taxonomy, the per-tab UI (`All` / `My Objects` / `Downstream` / `Upstream`) and its filter panel, the lifecycle (`OPEN` / `RESOLVED` / `RESOLVED_AUTOMATICALLY` plus the auto-resolution triggers, the manual-reopen guard, and the housekeeping-driven cleanup), and the per-entity halt-notification feature, see the [Alerting](/features/active-platform-features/alerting.md) feature page; for outbound notification dispatch (Slack / email / generic webhook) and the inbound AlertManager wiring, see [Notifications](/features/active-platform-features/notifications.md). Alert dispatch to Slack is platform-internal (driven by the WAL replication mechanism) and does not appear on this API surface — it's configured at [`notifications.receivers.slack.url`](/configuration-and-deployment/odd-platform.md#enable-alert-notifications) and is **distinct** from the [full Slack app](/developer-guides/api-reference/data-collaboration.md) used by Data Collaboration (`datacollaboration.slack-oauth-token`). **Global alert listings** The filterable listing and count queries behind the navigation pane's `Alerts` section. A single `getAlertsList` call backs all four tabs (selected via the `type` parameter), and `getAlertCounts` returns the per-tab badge counts. The `MY_OBJECTS`, `DOWNSTREAM`, and `UPSTREAM` view types require the signed-in user to be linked to an [Owner](/configuration-and-deployment/enable-security/authorization/user-owner-association.md); without the link, those views respond with empty pages. {% hint style="info" %} **`getAlertsList` applies no status filter unless you pass one.** When `status` is omitted the endpoint returns alerts in every lifecycle state. The global Alerts UI defaults the `status` parameter to `OPEN` (the active work queue) and lets the operator widen to `RESOLVED` / `RESOLVED_AUTOMATICALLY` via the Status filter — but that default is applied by the front-end, not the endpoint. Pass `status=RESOLVED` (or omit `status`) to read resolved history globally. {% endhint %} | Method | Path | Operation ID | Purpose | | ------ | -------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET` | `/api/alerts/list` | `getAlertsList` | Paginated list of alerts for the chosen view (`type` = `ALL` / `MY_OBJECTS` / `DOWNSTREAM` / `UPSTREAM`) with optional `begin_date`, `end_date`, `datasource_id`, `namespace_id`, `tag_ids`, `owner_ids`, and `status` filters. Ordered by event datetime descending. Returns `Alert[]`. Backs all four tabs. | | `GET` | `/api/alerts/counts` | `getAlertCounts` | Per-view alert counts (`total_count` / `my_objects_count` / `downstream_count` / `upstream_count`) for the given filters, returned as `AlertCountInfo`; used to render the badge counters. The counts react to the filters but not to the selected tab. | *Deprecated — kept working for backward compatibility, superseded by the two endpoints above:* | Method | Path | Operation ID | Status | Replacement | | ------ | ------------------------ | ---------------------------- | -------------- | ------------------------------------------------------------------------------------------------- | | `GET` | `/api/alerts` | `getAllAlerts` | **Deprecated** | `getAlertsList?type=ALL&status=OPEN` | | `GET` | `/api/alerts/my` | `getAssociatedUserAlerts` | **Deprecated** | `getAlertsList?type=MY_OBJECTS` | | `GET` | `/api/alerts/dependents` | `getDependentEntitiesAlerts` | **Deprecated** | `getAlertsList?type=DOWNSTREAM` (with the new `type=UPSTREAM` for the opposite lineage direction) | | `GET` | `/api/alerts/totals` | `getAlertTotals` | **Deprecated** | `getAlertCounts` | The legacy listing endpoints return the open-only `AlertList` shape (`status = OPEN` filtered at the database layer) and `getAlertTotals` returns `AlertTotals`; they remain mounted for existing clients but receive no new filter capability. New integrations should call `getAlertsList` / `getAlertCounts`. **Per-entity alert listings** | Method | Path | Operation ID | Purpose | | ------ | ------------------------------------------------------------------ | --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET` | `/api/dataentities/{data_entity_id}/alerts/list` | `getDataEntityAlertsList` | Paginated list of a single entity's alerts (the entity-page Alerts tab), with optional `begin_date`, `end_date`, and `status` filters. Ordered by event datetime descending. Returns `Alert[]`. With no `status` it returns the entity's open **and** resolved alerts — the per-entity tab defaults to showing all statuses, so resolved history stays visible. | | `GET` | `/api/dataentities/{data_entity_id}/alerts/counts?status={status}` | `getDataEntityAlertsCounts` | Count of alerts on the given entity at the given `status` (`OPEN` / `RESOLVED` / `RESOLVED_AUTOMATICALLY`). | *Deprecated — kept working for backward compatibility:* | Method | Path | Operation ID | Status | Replacement | | ------ | ------------------------------------------- | --------------------- | -------------- | ------------------------------------------------------------------------------------------------------------- | | `GET` | `/api/dataentities/{data_entity_id}/alerts` | `getDataEntityAlerts` | **Deprecated** | `getDataEntityAlertsList` (adds `begin_date` / `end_date` / `status` filters; same open-and-resolved default) | **Alert status mutation** | Method | Path | Operation ID | Purpose | | ------ | ------------------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `PUT` | `/api/alerts/{alert_id}/status` | `changeAlertStatus` | Resolve, auto-mark, or manually reopen an alert. Body: `AlertStatusFormData` carrying the target `AlertStatus` enum value. The activity feed records every transition as an `ALERT_STATUS_UPDATED` event. | {% hint style="info" %} **Manual reopen has a guard.** Setting the status back to `OPEN` is rejected with `400 Bad Request` and the message `Cannot reopen alert since the system already has an open alert of the same type` if another alert of the same type is already open on the same data entity. Resolve or work the newer alert first, or leave the older one closed. The guard is enforced in `AlertServiceImpl.updateStatus(...)` (see `AlertServiceImpl.java:124-131`). {% endhint %} **Per-entity halt-notification configuration** The halt configuration suppresses **new** alerts of a given type on a given entity until the configured timestamp passes. The toggle is per alert type and per entity; it is exposed on the entity's `Notification Settings` button in the UI and is also a thin REST surface. The platform records every change as an `ALERT_HALT_CONFIG_UPDATED` event on the [Activity Feed](/features/active-platform-features/activity-feed.md) (`AlertHaltConfigServiceImpl.saveAlertHaltConfig` is annotated `@ActivityLog`). For the operator-facing halt taxonomy, the five preset durations exposed on the UI, the suppress-only-creation semantics (auto-resolution still runs while halted), and the Distribution-anomaly known-limitation, see [Alerting → Halt notifications per entity](/features/active-platform-features/alerting.md#halt-notifications-per-entity). | Method | Path | Operation ID | Purpose | | ------ | ------------------------------------------------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `GET` | `/api/dataentities/{data_entity_id}/alert_config` | `getAlertConfig` | Read the current halt timestamps for the given entity. Returns a `DataEntityAlertConfig` with four fields (one per halt-able alert type — see below). Empty body means no halt is set. | | `PUT` | `/api/dataentities/{data_entity_id}/alert_config` | `updateAlertConfig` | Write the halt timestamps for the given entity. Body: `DataEntityAlertConfig`. Pass an ISO-8601 `date-time` per field to set a halt; pass `null` for a field to clear it. Returns the updated config (`201 Created`). | The four halt-timestamp fields on `DataEntityAlertConfig` (all optional, all `string ($date-time)`): | Field | Suppresses | Notes | | --------------------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `failed_job_halt_until` | New `Failed job` alerts. | Halt is enforced on the ingestion-driven alert-creation path. | | `failed_dq_test_halt_until` | New `Failed data quality test` alerts. | Halt is enforced on the ingestion-driven alert-creation path. | | `incompatible_schema_halt_until` | New `Backwards incompatible schema change` alerts. | Halt is enforced on the ingestion-driven alert-creation path. | | `distribution_anomaly_halt_until` | New `Distribution anomaly` alerts. | **Currently unenforced** — persisted by the API but ignored by the AlertManager-driven creation path. See [Alerting → Distribution anomaly halt is currently unenforced](/features/active-platform-features/alerting.md#distribution-anomaly-halt-is-currently-unenforced). | **Inbound AlertManager webhook** ODD also accepts Prometheus AlertManager notifications on a single inbound endpoint. Each inbound `alerts[]` entry is translated to a `Distribution Anomaly` alert on the data entity referenced by its `entity_oddrn` label. The endpoint is **not** covered by the OpenAPI spec (the AlertManager webhook payload is a Prometheus-defined contract) — the endpoint description, the accepted payload subset, the example AlertManager receiver configuration, and the operator-side authentication caveat (the endpoint is not behind the platform's ingestion auth filter) live with the operator-deployment context. | Method | Path | Purpose | | ------ | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | `POST` | `/ingestion/alert/alertmanager` | AlertManager webhook receiver. Returns `204 No Content` on success. The path is fixed in `AlertManagerController.java:21`. | For the payload subset accepted (`alerts[].labels`, `alerts[].generatorURL`, `alerts[].startsAt`), the example `alertmanager.yml` receiver configuration, the `entity_oddrn` label requirement, and the network-perimeter authentication options, see [Configure ODD Platform → Prometheus AlertManager Integration](/configuration-and-deployment/odd-platform.md#prometheus-alertmanager-integration). ## See also * [API Reference hub](/developer-guides/api-reference.md) — the full per-feature index. * [Alerting](/features/active-platform-features/alerting.md) — feature description, taxonomy, lifecycle, and the per-entity halt UI. * [Notifications](/features/active-platform-features/notifications.md) — outbound channels (Slack / email / generic webhook) and the Prometheus AlertManager inbound webhook.