Managing monitors with GraphQL

Monitors track a model or project’s drift, performance, and data quality metrics over time in Arize AX and alert you when something changes. The Configure Monitors guide covers monitor concepts (evaluation windows, baselines, thresholds) in the UI. Everything in that guide can also be done through the GraphQL API, which is the better path once you manage more than a handful of monitors: bulk threshold tuning, templated monitor creation across many features or models, and scheduled downtime. This guide assumes you already know how to form a GraphQL call with an x-api-key header against https://app.arize.com/graphql.

Find the IDs you need

Every monitor mutation takes a monitor ID, and every create mutation takes a model ID (or a space ID plus model name). Start from viewer to find your space, then the space’s models connection to find the model. See Using global node IDs for how these opaque IDs work.

query FindSpaceAndModel($spaceSearch: String, $modelSearch: String) {
  viewer {
    spaces(search: $spaceSearch, first: 5) {
      edges {
        node {
          id
          name
          models(search: $modelSearch, first: 5) {
            edges {
              node {
                id
                name
              }
            }
          }
        }
      }
    }
  }
}

{
  "spaceSearch": "Production",
  "modelSearch": "fraud"
}

Once you have a model’s or space’s ID, fetch any object directly with the node root field, for example node(id: "<MONITOR_ID>") { ... on Monitor { name } }.

List monitors for a model, filtered by status

Monitors live on both Model and Space through the same monitors connection, with filters for category and current status. This is the fastest way to find every triggered monitor on a model.

query TriggeredMonitorsForModel($modelId: ID!) {
  node(id: $modelId) {
    ... on Model {
      monitors(first: 50, currentStatus: [triggered]) {
        totalCount
        edges {
          node {
            id
            name
            monitorCategory
            status
            threshold
            latestComputedValue
          }
        }
      }
    }
  }
}

{
  "modelId": "<MODEL_ID>"
}

latestComputedValue is the monitor’s most recent computed metric value. It replaces the old currentMetricValue field, which no longer exists on Monitor.

Create a drift monitor on a feature with a custom baseline

Drift monitors compare a primary window against a baseline. By default a monitor uses the model’s primary baseline, but you can give it its own moving-window baseline instead, as shown here.

mutation CreateDriftMonitor($input: CreateDriftMonitorMutationInput!) {
  createDriftMonitor(input: $input) {
    monitor {
      id
      name
      uri
      threshold
    }
  }
}

{
  "input": {
    "modelId": "<MODEL_ID>",
    "name": "PSI drift on home_state",
    "driftMetric": "psi",
    "operator": "greaterThan",
    "dimensionCategory": "featureLabel",
    "dimensionName": "home_state",
    "dynamicAutoThreshold": { "stdDevMultiplier": 2 },
    "baseline": {
      "useModelPrimaryBaseline": false,
      "movingWindowSeconds": 1209600,
      "movingWindowDelaySeconds": 864000
    },
    "contacts": [
      { "notificationChannelType": "email", "emailAddress": "you@arize.com" }
    ]
  }
}

Reference: createDriftMonitor.

Create a performance monitor with contacts and a webhook

Performance monitors watch a metric like accuracy or recall and alert when it crosses a threshold. Pair an email contact with a webhook subscription so the same trigger reaches both a person and an external system. Webhooks must already exist as webhook destinations in your account; webhookId is that destination’s ID.

mutation CreatePerformanceMonitor($input: CreatePerformanceMonitorMutationInput!) {
  createPerformanceMonitor(input: $input) {
    monitor {
      id
      name
      uri
    }
  }
}

{
  "input": {
    "modelId": "<MODEL_ID>",
    "name": "Accuracy drop on production traffic",
    "performanceMetric": "accuracy",
    "operator": "lessThan",
    "threshold": 0.85,
    "contacts": [
      { "notificationChannelType": "email", "emailAddress": "oncall@arize.com" }
    ],
    "webhookSubscriptions": [
      {
        "webhookId": "<WEBHOOK_ID>",
        "subscribedWebhookEvents": ["MONITOR_TRIGGERED", "MONITOR_CLEARED"]
      }
    ]
  }
}

Reference: createPerformanceMonitor.

Create a data quality monitor

Data quality monitors watch a dimension-level metric, such as the percentage of empty values on a feature.

mutation CreateDataQualityMonitor($input: CreateDataQualityMonitorMutationInput!) {
  createDataQualityMonitor(input: $input) {
    monitor {
      id
      name
      uri
    }
  }
}

{
  "input": {
    "modelId": "<MODEL_ID>",
    "name": "Missing values on credit_score",
    "dimensionName": "credit_score",
    "dimensionCategory": "featureLabel",
    "dataQualityMetric": "percentEmpty",
    "operator": "greaterThan",
    "threshold": 0.05
  }
}

Reference: createDataQualityMonitor.

Raise the threshold on every drift monitor in a space

This is the most common bulk operation: pull every drift monitor in a space, then patch each one’s threshold. List first, mutate second, since patchDriftMonitor takes one monitor ID at a time.

query DriftMonitorsInSpace($spaceId: ID!, $after: String) {
  node(id: $spaceId) {
    ... on Space {
      monitors(first: 100, after: $after, monitorCategory: drift) {
        pageInfo { hasNextPage endCursor }
        edges { node { id name threshold dynamicAutoThresholdEnabled } }
      }
    }
  }
}

mutation RaiseDriftThreshold($monitorId: ID!, $threshold: Float!) {
  patchDriftMonitor(
    input: { monitorId: $monitorId, set: { threshold: $threshold, dynamicAutoThresholdEnabled: false } }
  ) {
    monitor { id threshold }
  }
}

import requests

GRAPHQL_URL = "https://app.arize.com/graphql"
HEADERS = {"x-api-key": "<YOUR_API_KEY>", "Content-Type": "application/json"}

# Same documents as the Query and Mutation tabs above.
LIST_QUERY = """
query DriftMonitorsInSpace($spaceId: ID!, $after: String) {
  node(id: $spaceId) {
    ... on Space {
      monitors(first: 100, after: $after, monitorCategory: drift) {
        pageInfo { hasNextPage endCursor }
        edges { node { id name threshold } }
      }
    }
  }
}
"""
PATCH_MUTATION = """
mutation RaiseDriftThreshold($monitorId: ID!, $threshold: Float!) {
  patchDriftMonitor(
    input: { monitorId: $monitorId, set: { threshold: $threshold, dynamicAutoThresholdEnabled: false } }
  ) {
    monitor { id threshold }
  }
}
"""


def run(query, variables):
    resp = requests.post(GRAPHQL_URL, headers=HEADERS, json={"query": query, "variables": variables})
    resp.raise_for_status()
    payload = resp.json()
    if payload.get("errors"):
        raise RuntimeError(payload["errors"])
    return payload["data"]

def raise_drift_thresholds(space_id, multiplier=1.1):
    after = None
    while True:
        connection = run(LIST_QUERY, {"spaceId": space_id, "after": after})["node"]["monitors"]
        for edge in connection["edges"]:
            monitor = edge["node"]
            new_threshold = monitor["threshold"] * multiplier
            run(PATCH_MUTATION, {"monitorId": monitor["id"], "threshold": new_threshold})
            print(f"{monitor['name']}: {monitor['threshold']} -> {new_threshold}")
        if not connection["pageInfo"]["hasNextPage"]:
            break
        after = connection["pageInfo"]["endCursor"]

raise_drift_thresholds("<SPACE_ID>")

Setting dynamicAutoThresholdEnabled: false alongside the new threshold matters: if a monitor already has dynamic auto-thresholds on, a manual threshold write is otherwise overwritten the next time the monitor recalculates. Reference: patchDriftMonitor.

Switch a monitor to dynamic auto-thresholds

Instead of a fixed threshold, a monitor can recompute its threshold on a schedule as mean +/- stdDevMultiplier * stdDev. This works on any monitor type through the generic patchMonitor mutation.

mutation EnableAutoThreshold($monitorId: ID!, $stdDevMultiplier: Float!) {
  patchMonitor(
    input: {
      monitorId: $monitorId
      set: {
        dynamicAutoThresholdEnabled: true
        dynamicAutoThreshold: { stdDevMultiplier: $stdDevMultiplier }
      }
    }
  ) {
    monitor {
      id
      dynamicAutoThresholdEnabled
      threshold
    }
  }
}

{
  "monitorId": "<MONITOR_ID>",
  "stdDevMultiplier": 2
}

Reference: patchMonitor.

Schedule recurring downtime for a monitor

Downtime suppresses evaluation for a window that repeats on a cadence, useful for known maintenance windows or batch jobs that temporarily skew a metric.

mutation ScheduleDowntime(
  $monitorId: ID!
  $downtimeStart: DateTime!
  $durationHrs: PositiveInt!
  $frequencyDays: PositiveInt!
) {
  patchMonitor(
    input: {
      monitorId: $monitorId
      set: {
        downtimeStart: $downtimeStart
        downtimeDurationHrs: $durationHrs
        downtimeFrequencyDays: $frequencyDays
      }
    }
  ) {
    monitor {
      id
      downtimeStart
      downtimeDurationHrs
      downtimeFrequencyDays
    }
  }
}

{
  "monitorId": "<MONITOR_ID>",
  "downtimeStart": "2026-01-01T00:00:00Z",
  "durationHrs": 4,
  "frequencyDays": 7
}

downtimeDurationHrs must be between 1 and 1344 hours (56 days), and downtimeFrequencyDays between 1 and 56 days. Reference: patchMonitor.

Trigger a monitor manually, then delete it

triggerMonitor forces an off-schedule evaluation, which is useful after you change a threshold and want to confirm the new condition immediately rather than waiting for the next evaluation interval. deleteMonitor removes a monitor permanently; there is no undo.

mutation TriggerMonitor($monitorId: ID!) {
  triggerMonitor(input: { monitorId: $monitorId }) {
    success
    monitor {
      id
      isTriggered
      status
    }
  }
}

mutation DeleteMonitor($monitorId: ID!) {
  deleteMonitor(input: { monitorId: $monitorId }) {
    monitor {
      id
    }
  }
}

{
  "monitorId": "<MONITOR_ID>"
}

Reference: triggerMonitor, deleteMonitor.

Gotchas and behavior notes

currentMetricValue and a patched autoThresholdEnabled are not real. Older examples query currentMetricValue on Monitor, which does not exist; use latestComputedValue instead. Older examples also patch autoThresholdEnabled inside a set input, but the patch inputs (DriftMonitorPatchInput, PerformanceMonitorPatchInput, DataQualityMonitorPatchInput, MonitorPatchInput) only accept dynamicAutoThresholdEnabled. Monitor exposes both autoThresholdEnabled and dynamicAutoThresholdEnabled as read fields, which is easy to confuse with the patch-only name.
Patched filters and modelVersions fully replace, not merge. On every patch input, supplying either array replaces the monitor’s existing list entirely. There is no append or partial update.
You cannot change a monitor’s metric type or dimension with a patch. driftMetric, performanceMetric, dataQualityMetric, dimensionName, and dimensionCategory are set only at creation; no patch input exposes them. Delete and recreate the monitor to change what it measures.
Range thresholds need the second set of fields. thresholdMode defaults to single. Set it to range and also supply threshold2, operator2, and optionally stdDevMultiplier2 to alert on both a lower and an upper bound.
Evaluation window and delay are in seconds, not hours. evaluationWindowLengthSeconds and delaySeconds are both seconds despite their schema descriptions mentioning hours. The default evaluation window is 259200 seconds (3 days).
Account-level monitor usage limits are deprecated. Account.monitorUsage is marked deprecated in the schema: monitors are no longer capped per pricing tier, so limit is always null and limitReached is always false.
Integration contacts need an integration key, not an email. MonitorContactInput.notificationChannelType defaults to email. For a paging or chat integration, set it to integration and pass integrationKeyId instead of emailAddress. Integration keys are created separately and are not part of the monitors mutations covered here.

Monitor mutations reference

Full argument and field listing for all nine monitor mutations.

All GraphQL mutations

Browse mutations for every other domain.

API explorer

Try queries and mutations interactively with autocomplete.

Skills

MCP server

API reference

API clients

Managing monitors with GraphQL

Find the IDs you need

List monitors for a model, filtered by status

Create a drift monitor on a feature with a custom baseline

Create a performance monitor with contacts and a webhook

Create a data quality monitor

Raise the threshold on every drift monitor in a space

Switch a monitor to dynamic auto-thresholds

Schedule recurring downtime for a monitor

Trigger a monitor manually, then delete it

Gotchas and behavior notes

Monitor mutations reference

All GraphQL mutations

API explorer

​Find the IDs you need

​List monitors for a model, filtered by status

​Create a drift monitor on a feature with a custom baseline

​Create a performance monitor with contacts and a webhook

​Create a data quality monitor

​Raise the threshold on every drift monitor in a space

​Switch a monitor to dynamic auto-thresholds

​Schedule recurring downtime for a monitor

​Trigger a monitor manually, then delete it

​Gotchas and behavior notes

Monitor mutations reference

All GraphQL mutations

API explorer

Find the IDs you need

List monitors for a model, filtered by status

Create a drift monitor on a feature with a custom baseline

Create a performance monitor with contacts and a webhook

Create a data quality monitor

Raise the threshold on every drift monitor in a space

Switch a monitor to dynamic auto-thresholds

Schedule recurring downtime for a monitor

Trigger a monitor manually, then delete it

Gotchas and behavior notes