vercel monitors

The vercel monitors command manages monitors (the rules that decide when Edgenivo alerts your team) from the terminal. It replaces the deprecated vercel alerts rules command tree.

Use monitor schemas to inspect the fields available to your selected team, then create, list, inspect, update, or delete monitors.

Use vercel monitors --help to see the command tree.

Monitor IDs are returned by monitors add and shown by monitors ls. Use those IDs with monitors inspect, monitors update, and monitors rm.

# List monitors for the linked project
vercel monitors ls
 
# Add a monitor from a JSON body file
vercel monitors add --project my-app --body ./monitor.json

List monitors that affect the linked project. Use --project to select another project or --all to list every accessible monitor in the selected team.

Aliases: list.

vercel monitors ls

Use built-in to list built-in monitors. For compatibility with previous CLI versions, monitors ls --type also accepts supported built-in trigger types such as usage_anomaly and error_anomaly. Use vercel monitors schema --type built-in to inspect the trigger types available to your team.

Use custom to list custom monitors. For compatibility with previous CLI versions, the option also accepts custom_alert.

# List monitors for the linked project
vercel monitors ls
 
# List every monitor in the selected team
vercel monitors ls --all
 
# JSON output
vercel monitors ls --all --format json

List custom monitors affecting a specific project:

vercel monitors ls --project my-app --type custom

monitors ls retrieves every available page before printing results. JSON output contains a monitors array with the matching monitor objects.

Fetch the API-owned authoring schema for the monitor types available to the selected team. Run the command without --type to list the available types, or select a type to see its create and update fields, constraints, and examples.

vercel monitors schema

# Show the fields and examples for built-in monitors
vercel monitors schema --type built-in

Show the fields and examples for custom monitors:

vercel monitors schema --type custom
vercel monitors schema --type custom --format json

For custom monitors, run vercel metrics schema <metric-or-prefix> before authoring the body. The command returns current metric names, aggregations, dimensions, and filter fields. Use a returned metric name directly in evaluation.query.metrics.<alias>.metric.

Add a monitor from a JSON body file. The request body must set type. For a built-in monitor, set type to built-in. For a custom monitor, set type to custom.

create remains a deprecated compatibility alias, but prints a deprecation warning. Use add for new commands.

vercel monitors add --project my-app --body ./monitor.json

Custom monitors require --project and do not support --all.

Create a JSON file for the monitor body, then select the monitor's project scope in one of these ways:

• Add ruleScope to the body.
• Pass --project <name-or-id>.
• Pass --all for a built-in monitor.

Do not combine ruleScope with --project or --all. A linked project does not supply the scope automatically when you add a monitor.

Add a built-in error anomaly monitor for one project:

{
  "type": "built-in",
  "name": "Production server errors",
  "triggers": {
    "mode": "selected",
    "items": [
      {
        "type": "error_anomaly",
        "filter": "statusGroup:5xx AND route:/api/*"
      }
    ]
  },
  "matchMinimumSeverityLevel": "high"
}

vercel monitors add --project my-app --body ./monitor.json

Use vercel monitors schema --type built-in for additional validated examples, filter syntax, and current constraints.

Add a custom threshold monitor for one project:

{
  "type": "custom",
  "name": "Checkout server errors",
  "severity": "high",
  "evaluation": {
    "window": "5m",
    "query": {
      "metrics": {
        "errors": {
          "metric": "vercel.request.count",
          "aggregation": "count",
          "filter": "httpStatus >= 500"
        }
      },
      "outputs": ["errors"]
    }
  },
  "trigger": {
    "type": "threshold",
    "output": "errors",
    "operator": "gt",
    "threshold": 20
  }
}

vercel monitors add --project my-app --body ./monitor.json

Use vercel monitors schema --type custom for additional validated examples, filter syntax, and current constraints.

The current command rejects request bodies that contain the previous alertTypes field. Rewrite saved bodies using the current schema:

Built-in filters use the syntax shown by the current schema. For example, an error anomaly filter uses statusGroup:5xx instead of the previous OData expression.

The current command also rejects request bodies that contain the previous customAlert or queryJsonString fields. Rewrite custom monitor fields using the current schema:

Custom filters use the syntax shown by the current schema.

Show one monitor by ID.

Aliases: get.

Monitor IDs are unique within a team. Use the global --scope <team> option when the monitor belongs to a team other than your current team.

vercel monitors inspect <monitorId>

vercel monitors inspect ar_abc123
vercel monitors inspect ar_abc123 --format json

Delete a monitor. The selected team's default monitor cannot be deleted.

Aliases: remove, delete.

Monitor IDs are unique within a team. Use the global --scope <team> option when the monitor belongs to a team other than your current team.

vercel monitors rm <monitorId>

# Delete with confirmation
vercel monitors rm ar_abc123
 
# Delete without prompt
vercel monitors rm ar_abc123 --yes
 
# Delete by using the delete alias
vercel monitors delete ar_abc123 --yes

Patch a monitor from a JSON body file, change its project scope, or do both. Omitted body fields remain unchanged, and type is optional because the API infers it from the stored monitor.

Aliases: patch.

vercel monitors update <monitorId> --body ./patch.json
vercel monitors update <monitorId> --project my-app

You must provide --body, --project, or --all. Do not combine a ruleScope field in the body with --project or --all.

Custom monitors require --project and do not support --all.

Save the fields you want to change in a JSON file:

{
  "name": "Critical production errors",
  "matchMinimumSeverityLevel": "critical"
}

# Update fields from a file
vercel monitors update ar_abc123 --body ./patch.json
 
# Patch by using the patch alias
vercel monitors patch ar_abc123 --body ./patch.json
 
# Change scope without a body file
vercel monitors update ar_abc123 --project my-app

The authoring schema includes restrictions based on the stored monitor. For example, the default monitor accepts notification updates only.

A custom monitor with querySupported: false accepts changes to name, severity, and notificationSettings only.

Use --format json for scripting and automation. Monitor commands write only JSON to standard output:

Validation failures return an error object with code and message. When the API identifies individual invalid fields, the object also includes an issues array with field paths and messages.

vercel monitors replaces the deprecated vercel alerts rules command tree. The options and request bodies are unchanged:

JSON output renames the rule keys to monitor keys: rules becomes monitors, ruleTypes becomes monitorTypes, rule becomes monitor, and ruleId becomes monitorId. Update scripts that read these fields when you migrate. See JSON output for the current shapes.

• To learn how to configure and receive alerts, see Alerts.
• To configure monitors from the dashboard, see Configure alerts.
• To list and inspect the alerts your monitors raise, see vercel alerts.

The following global options can be passed when using the vercel monitors command:

• --cwd
• --debug
• --global-config
• --help
• --local-config
• --no-color
• --non-interactive
• --scope
• --team
• --token
• --version

For more information on global options and their usage, refer to the options section.