Monitoring quickstart

Overview

Monitoring lets you automatically track quality and detect issues across your voice AI agents. Instead of manually reviewing calls, you define monitors that continuously evaluate your call data against thresholds and alert you when something goes wrong.

What is monitoring?

Monitoring is Vapi’s automated quality and effectiveness system for voice AI. You create monitors that periodically evaluate call data using analytics queries (Insights), compare results against thresholds you define, and generate issues when those thresholds are exceeded. Your team receives alerts through notifiers, which are alert channels such as email, Slack, or webhooks, so you can investigate and resolve problems quickly.

Core concepts

• Monitors define what to watch, which assistants to target, and when to evaluate
• Triggers run on a schedule and evaluate call data against thresholds
• Issues are created when a threshold is exceeded and a trigger fires, tracking the problem from detection to resolution
• Notifiers are alert channels (email, Slack, or webhook) that deliver notifications to your team when issues are created

Monitor categories

Categories help you organize and route monitors. Technical and Infrastructure monitors currently share the same trigger options, so the metric either category evaluates is defined by the Insight attached to its trigger. Effectiveness and Compliance monitors use a separate evaluation flow based on call transcripts and structured outputs.

• Technical groups issues in your own integrations and configuration, such as API errors, provider outages, and timeouts
• Infrastructure groups platform-level issues, such as capacity and resource limits
• Effectiveness groups assistant performance metrics like task completion and user satisfaction
• Compliance groups regulatory and policy adherence across conversations

What you’ll build

In this quickstart, you will create a monitor that tracks error rates across your assistants and alerts you when the number of errors exceeds a threshold. You will then view an issue, analyze its root cause, and resolve it.

How it works

Prerequisites

Step 1: Set up notifiers

Notifiers are alert channels (email, Slack, or webhook) that send notifications when issues are detected. You configure them as credentials in the Dashboard.

Webhook payload

When a webhook notifier is attached to a trigger, Vapi sends a single POST request the moment an issue is created. The body is the same envelope every time, wrapped in a message object:

1
{
2
  "message": {
3
    "type": "issue.created",
4
    "timestamp": 1752574205000,
5
    "orgId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
6
    "issue": {
7
      "id": "e5f6a7b8-c9d0-1234-efab-567890123456",
8
      "status": "created",
9
      "totalCalls": 150,
10
      "failingCalls": 12,
11
      "evaluationStartAt": "2025-07-15T09:30:00.000Z",
12
      "createdAt": "2025-07-15T10:30:00.000Z"
13
    },
14
    "monitor": {
15
      "id": "550e8400-e29b-41d4-a716-446655440000",
16
      "name": "Error Rate Monitor",
17
      "description": "Tracks API and provider errors across all assistants",
18
      "category": "technical",
19
      "trigger": {
20
        "id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
21
        "threshold": { "type": "number", "comparator": "gt", "value": 5 },
22
        "severity": "error",
23
        "insight": {
24
          "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
25
          "name": "Error count",
26
          "type": "text"
27
        }
28
      }
29
    }
30
  }
31
}

Field reference

One webhook per issue

Vapi sends the webhook once, when the issue is first created. There are no issue.updated or issue.resolved webhooks. If the problem persists across evaluation windows, Vapi updates the same non-resolved issue with newly affected calls and does not send another webhook. After that issue is resolved, a later threshold breach creates a new issue and sends a new issue.created webhook. Acknowledging or resolving an issue happens in the Dashboard or via PATCH /monitoring/issue/:id and does not emit a webhook.

By default, delivery is attempted once per notifier. If a backoff plan is configured for the webhook notifier’s server, failed requests can be retried. The final delivery result is recorded in the issue’s alerts array, so a "failure" status there means the notification could not be delivered (see Troubleshooting).

Step 2: Create a monitor

Define a monitor that tracks error rates and alerts you when errors exceed a threshold.

Managing monitors

View, edit, and delete all your monitors from the Monitors page in the Dashboard sidebar (under Observe).

Via the API:

• GET /monitoring/monitor — list all monitors
• PATCH /monitoring/monitor/:id — update a monitor’s targets, triggers, or thresholds
• DELETE /monitoring/monitor/:id — remove a monitor

Targeting assistants

Setting "targets": "*" monitors all current and future assistants in your organization. Any assistant created after the monitor is set up is automatically included.

To monitor only specific assistants, pass an array of assistant IDs using the targets array. The id field is the assistant ID — the UUID you see in the Dashboard or get from GET /assistant.

1
{
2
  "targets": [
3
    {
4
      "type": "assistant",
5
      "id": "c3d4e5f6-a7b8-9012-cdef-234567890abc"
6
    },
7
    {
8
      "type": "assistant",
9
      "id": "d4e5f6a7-b8c9-0123-defa-345678901bcd"
10
    }
11
  ]
12
}

Schedule-based triggers

Instead of an interval, you can use a calendar schedule for more precise control:

1
{
2
  "insightId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
3
  "schedule": {
4
    "minute": [0],
5
    "hour": [9, 17],
6
    "dayOfWeek": [1, 2, 3, 4, 5]
7
  },
8
  "threshold": {
9
    "type": "number",
10
    "comparator": "gt",
11
    "value": 10
12
  },
13
  "severity": "warning"
14
}

This trigger evaluates at 9:00 AM and 5:00 PM on weekdays.

Step 3: View issues

When a threshold is exceeded and a trigger fires, an issue is created. You can view and manage issues in the Dashboard or via the API.

Step 4: Analyze an issue

Use AI-powered root cause analysis to understand why an issue occurred and get actionable suggestions for fixing it.

Step 5: Resolve an issue

After investigating and fixing the underlying problem, acknowledge and resolve the issue to track your team’s response. Resolve an issue once you’ve deployed a fix and confirmed the problem no longer recurs — this signals to your team that the root cause has been addressed. Acknowledgment and resolution timestamps help measure your team’s incident response times.

Troubleshooting

Next steps

Get help

Need assistance? We’re here to help:

• Discord Community
• Support