Part of the Phoenix Alerts Management API reference.

This article covers viewing and acting on alerts once they exist. To send an alert in from your monitoring tool, see Sending alerts.

List alerts

GET /v1/alerts

Filter with repeated or comma-separated query params: status, severity_level, team_uuid, service_uuid. Date-range filters created_after and created_before accept ISO-8601 datetimes. Page size defaults to 50 (max 200); pass cursor from the previous response's next_cursor for the next page.

Response (200):

{
  "object": "list",
  "data": [
    {
      "object": "alert",
      "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "alert_number": 42,
      "alert_key": "server.cpu.high",
      "status": "TRIGGERED",
      "severity_level": 2,
      "service": {
        "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
        "name": "API Service",
        "key": "api-service"
      },
      "team": {
        "id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
        "name": "Platform Team",
        "key": "platform"
      },
      "summary": "CPU usage above 90% for 5 minutes",
      "source": "datadog",
      "duplicate_count": 0,
      "created_at": "2026-06-12T00:00:00.000Z",
      "updated_at": "2026-06-12T00:00:00.000Z",
      "acknowledged_at": null,
      "resolved_at": null,
      "occurred_at": "2026-06-12T00:00:00.000Z",
      "unrouted_reason": null
    }
  ],
  "next_cursor": null,
  "has_more": false
}

Get a single alert

GET /v1/alerts/{alert_uuid}

The path accepts either the alert's UUID or its per-account alert number (42).

This returns everything the list endpoint does, plus status_history, notification_attempts, and a permissions block (can_acknowledge, can_resolve) computed for your credential. Add ?expand=timeline to embed the first page of the event timeline in the same response.

Acknowledge or resolve

PATCH /v1/alerts/{alert_uuid}

Example request body:

{"status": "ACKNOWLEDGED"}

status is "ACKNOWLEDGED" or "RESOLVED". This endpoint also accepts an ingestion key (pi_) — useful if your monitoring tool resolves the alert on its own once the underlying issue clears.

Re-route or escalate an alert

PATCH /v1/alerts/{alert_uuid} also accepts these fields, each mutually exclusive with status and each other:

Field	Notes
`service_uuid`	Re-route the alert to a different service.
`team_uuid`	Re-route the alert to a different team.
`summary`	Update the alert's summary text (1–4096 characters).
`severity_level`	Update the severity (1–5).
`escalate_to_step`	Manually jump to a specific step in the alert's escalation policy, firing it immediately. Must be a later step than the current one.

Example request body:

{"escalate_to_step": 2}

View the event timeline

GET /v1/alerts/{alert_uuid}/timeline

Returns a cursor-paginated, newest-first list of everything that happened to the alert — status transitions, escalation steps firing, notification attempts, and routing decisions:

{
  "items": [
    {
      "position": 1,
      "kind": "transition",
      "occurred_at": "2026-06-12T00:00:00.000Z",
      "actor_type": "SYSTEM",
      "actor_id": null,
      "actor_label": null,
      "actor_channel": null,
      "meta": {"from_status": null, "to_status": "TRIGGERED"}
    }
  ],
  "next_cursor": null,
  "has_more": false
}