---
title: "POST /monitors"
method: POST
path: "/monitors"
tags: ["Monitors"]
---

# POST /monitors

`POST /monitors`

## Request

- Base URL: `https://api.axiom.co/v2`
- URL: `https://api.axiom.co/v2/monitors`
- Auth: OAuth 2
  - Authorization code: `https://accounts.google.com/o/oauth2/v2/auth`
  - Token URL: `https://www.googleapis.com/oauth2/v4/token` scopes: `monitors|create`
- TypeScript: <https://skmtc.dev/axiom/apis/axiom-public-api/docs/monitors/post.ts> (a function with typed inputs; its response is checked against the schema)

Creates a monitor. Axiom runs the monitor's query once before saving it and rejects the request if the query fails, for example because it's invalid or references a dataset that doesn't exist. `labelIds` replaces assignments when supplied; [] clears them. Omitted or null `labelIds` preserves assignments on updates and creates an unlabeled resource on creation. IDs must belong to existing labels in your organization and are validated before saving.

## Request body

- MonitorUpsertRequest: Configuration for a monitoring rule. Monitors can be configured to: - Check threshold values (e.g., CPU usage > 90%) - Match specific events in logs - Detect anomalies based on historical patterns Each monitor runs on a specified interval and can trigger notifications through configured notifiers.
  - `alertOnNoData` boolean: Whether to alert when no data is received
  - `aplQuery` string: APL (Axiom Processing Language) query string used for monitoring. This query defines what data to analyze and how to process it. At least one of aplQuery or mplQuery must be provided.
  - `columnName` string: Name of the column to monitor
  - `compareDays` number: Number of days to compare for anomaly detection
  - `description` string: Detailed description of the monitor's purpose
  - `disabled` boolean: Whether the monitor is currently disabled
  - `disabledUntil` string, date-time, nullable: Timestamp until when the monitor should remain disabled
  - `includeChart` boolean: Whether to include a query chart in triggered notifications
  - `intervalMinutes` integer: How frequently the monitor should run, in minutes. Minimum value is 1 minute.
  - `mplQuery` string: MPL (Metrics Processing Language) query string for metrics-based monitoring. Use this as an alternative to aplQuery for metrics datasets. At least one of aplQuery or mplQuery must be provided.
  - `name` string, required: Name of the monitor
  - `notifierIds` string[]: List of notifier IDs that will receive alerts. Notifiers can be email, Slack, webhook endpoints, etc.
  - `notifyByGroup` boolean: Whether to group notifications
  - `notifyEveryRun` boolean: Whether to send notifications on every check
  - `operator` 'Below' | 'BelowOrEqual' | 'Above' | 'AboveOrEqual' | 'AboveOrBelow': Comparison operator for threshold checks: - Below: Trigger when value < threshold - BelowOrEqual: Trigger when value <= threshold - Above: Trigger when value > threshold - AboveOrEqual: Trigger when value >= threshold - AboveOrBelow: Trigger when value is outside a range
  - `rangeMinutes` integer: Time window to evaluate in each check, in minutes. For example, "last 5 minutes of data"
  - `resolvable` boolean: Whether the alert can be manually resolved
  - `secondDelay` number: Number of seconds to move each run's query window into the past, so data that arrives late is included. For example, with a value of 300, a run at 10:05 queries up to 10:00.
  - `skipResolved` boolean: Whether to skip resolved alerts
  - `threshold` number, double: Threshold value for triggering the alert
  - `tolerance` number: Tolerance percentage for anomaly detection
  - `triggerAfterNPositiveResults` number: Number of runs among the last `triggerFromNRuns` runs, including the current one, that must meet the trigger condition for the monitor to trigger. The current run must always meet it. For example, set both fields to 3 to trigger only after 3 consecutive runs meet the condition. If unset or 0, the first run that meets the condition triggers. Values above `triggerFromNRuns` are lowered to it when the monitor is saved. Applies to Threshold and AnomalyDetection monitors.
  - `triggerFromNRuns` number: Number of most recent runs, including the current one, that the monitor looks at when deciding whether to trigger. Has no effect unless `triggerAfterNPositiveResults` is also set. Applies to Threshold and AnomalyDetection monitors.
  - `type` 'Threshold' | 'MatchEvent' | 'AnomalyDetection', required: Type of monitoring check to perform: - Threshold: Compares a numeric value against a threshold - MatchEvent: Looks for specific events or patterns - AnomalyDetection: Identifies unusual patterns based on historical data
  - `labelIds` LabelID[]: Existing label IDs; replaces assignments when supplied, clears with [], and preserves them when omitted or null.

## Response `200`

Created monitor.

- MonitorWithId: Configuration for a monitoring rule. Monitors can be configured to: - Check threshold values (e.g., CPU usage > 90%) - Match specific events in logs - Detect anomalies based on historical patterns Each monitor runs on a specified interval and can trigger notifications through configured notifiers.
  - `alertOnNoData` boolean: Whether to alert when no data is received
  - `aplQuery` string: APL (Axiom Processing Language) query string used for monitoring. This query defines what data to analyze and how to process it. At least one of aplQuery or mplQuery must be provided.
  - `columnName` string: Name of the column to monitor
  - `compareDays` number: Number of days to compare for anomaly detection
  - `description` string: Detailed description of the monitor's purpose
  - `disabled` boolean: Whether the monitor is currently disabled
  - `disabledUntil` string, date-time, nullable: Timestamp until when the monitor should remain disabled
  - `includeChart` boolean: Whether to include a query chart in triggered notifications
  - `intervalMinutes` integer: How frequently the monitor should run, in minutes. Minimum value is 1 minute.
  - `mplQuery` string: MPL (Metrics Processing Language) query string for metrics-based monitoring. Use this as an alternative to aplQuery for metrics datasets. At least one of aplQuery or mplQuery must be provided.
  - `name` string, required: Name of the monitor
  - `notifierIds` string[]: List of notifier IDs that will receive alerts. Notifiers can be email, Slack, webhook endpoints, etc.
  - `notifyByGroup` boolean: Whether to group notifications
  - `notifyEveryRun` boolean: Whether to send notifications on every check
  - `operator` 'Below' | 'BelowOrEqual' | 'Above' | 'AboveOrEqual' | 'AboveOrBelow': Comparison operator for threshold checks: - Below: Trigger when value < threshold - BelowOrEqual: Trigger when value <= threshold - Above: Trigger when value > threshold - AboveOrEqual: Trigger when value >= threshold - AboveOrBelow: Trigger when value is outside a range
  - `rangeMinutes` integer: Time window to evaluate in each check, in minutes. For example, "last 5 minutes of data"
  - `resolvable` boolean: Whether the alert can be manually resolved
  - `secondDelay` number: Number of seconds to move each run's query window into the past, so data that arrives late is included. For example, with a value of 300, a run at 10:05 queries up to 10:00.
  - `skipResolved` boolean: Whether to skip resolved alerts
  - `threshold` number, double: Threshold value for triggering the alert
  - `tolerance` number: Tolerance percentage for anomaly detection
  - `triggerAfterNPositiveResults` number: Number of runs among the last `triggerFromNRuns` runs, including the current one, that must meet the trigger condition for the monitor to trigger. The current run must always meet it. For example, set both fields to 3 to trigger only after 3 consecutive runs meet the condition. If unset or 0, the first run that meets the condition triggers. Values above `triggerFromNRuns` are lowered to it when the monitor is saved. Applies to Threshold and AnomalyDetection monitors.
  - `triggerFromNRuns` number: Number of most recent runs, including the current one, that the monitor looks at when deciding whether to trigger. Has no effect unless `triggerAfterNPositiveResults` is also set. Applies to Threshold and AnomalyDetection monitors.
  - `type` 'Threshold' | 'MatchEvent' | 'AnomalyDetection', required: Type of monitoring check to perform: - Threshold: Compares a numeric value against a threshold - MatchEvent: Looks for specific events or patterns - AnomalyDetection: Identifies unusual patterns based on historical data
  - `createdAt` string, date-time: Timestamp when the monitor was created
  - `createdBy` string: ID of the user who created the monitor
  - `createdByAgent` boolean: true when the MCP server created this monitor
  - `datasets` string[]: Dataset names referenced by the monitor query.
  - `id` string, required: Unique identifier for the monitor
  - `labelIds` LabelID[], required: IDs of labels assigned to this monitor.
  - `labelNames` string[], required: Names of assigned labels, including with exclude=labels; [] when unassigned.
  - `labels` Label[]: Resolved labels assigned to this monitor.
    - `color` LabelColor, required
      - `name` 'red' | 'coral' | 'orange' | 'amber' | 'yellow' | 'lime' | 'green' | 'teal' | 'blue' | 'iris' | 'purple' | 'pink', required
      - `type` 'palette', required
    - `description` string, nullable
    - `id` string, required
    - `name` string, required
  - `lastError` string: Most recent error encountered while evaluating the monitor.
  - `updatedAt` string, date-time: Timestamp when the monitor was last updated

## Other responses

- `400`: Bad request

## Changes

- **2026-11-04** (v2) `ce3b16fc7723`: 1 breaking, 2 warning, 1 info
  - removed the enum value `NewValues` of the request property `allOf[#/components/schemas/Monitor]/type`
  - removed the request property `allOf[#/components/schemas/Monitor]/lookbackDays`
  - removed the optional property `allOf[#/components/schemas/Monitor]/lookbackDays` from the response with the `200` status
  - removed the `NewValues` enum value from the `allOf[#/components/schemas/Monitor]/type` response property for the response status `200`
- **2026-11-02** (v2) `e3baf3b85e8d`: 2 breaking, 24 warning, 4 info
  - added `#/components/schemas/Monitor, subschema #2` to the request body `allOf` list
  - the request's body type changed from `object` to no type
  - removed the request property `alertOnNoData`
  - removed the request property `aplQuery`
  - …26 more
- **2026-10-16** (v2) `fbc1b8430feb`: 1 info
  - added the non-success response with the status `400`
- **2026-10-14** (v2) `8920e1697284`: 6 warning, 7 info
  - removed the request property `createdAt`
  - removed the request property `createdBy`
  - removed the request property `updatedAt`
  - removed the optional property `allOf[#/components/schemas/Monitor]/createdAt` from the response with the `200` status
  - …9 more

[Operation history](https://skmtc.dev/axiom/apis/axiom-public-api/changes/monitors/post.md)

---

[API](https://skmtc.dev/axiom/apis/axiom-public-api.md) - [All operations](https://skmtc.dev/axiom/apis/axiom-public-api/llms.txt) - [OpenAPI document](https://skmtc.dev/axiom/apis/axiom-public-api/revisions/7e39a295e3ba?raw)
