# 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` / `Dependents`), 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 three tab queries on the navigation pane's `Alerts` section, plus a totals call used to render the badge counters. `My Objects` and `Dependents` require the signed-in user to be linked to an [Owner](/configuration-and-deployment/enable-security/authorization/user-owner-association.md); without the link, both endpoints respond with empty pages. | Method | Path | Operation ID | Purpose | | ------ | ------------------------ | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `GET` | `/api/alerts` | `getAllAlerts` | Paginated list of every alert across the whole platform (back-end of the `All` tab). | | `GET` | `/api/alerts/my` | `getAssociatedUserAlerts` | Paginated list of alerts on data entities where the signed-in user is a registered owner (back-end of the `My Objects` tab). | | `GET` | `/api/alerts/dependents` | `getDependentEntitiesAlerts` | Paginated list of alerts on entities downstream (via lineage) of entities the signed-in user owns (back-end of the `Dependents` tab). | | `GET` | `/api/alerts/totals` | `getAlertTotals` | Open-alert counts for each of the three tabs above; used to render the badge counters in the navigation pane. | **Per-entity alert listings** | Method | Path | Operation ID | Purpose | | ------ | ------------------------------------------------------------------ | --------------------------- | ----------------------------------------------------------------------------------------------------------- | | `GET` | `/api/dataentities/{data_entity_id}/alerts` | `getDataEntityAlerts` | Paginated list of alerts on a single entity (the entity-page Alerts tab). | | `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`). | **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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.opendatadiscovery.org/developer-guides/api-reference/alerts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.