Alerts

Configure when your MCP server alerts your team, how it recovers, and where notifications are delivered.

Open Alerts in your server sidebar, below Domains. Pick a template or choose Create alert, edit the YAML, and save. Templates provide a starting configuration; later template changes do not change alerts you already created.

The table shows each alert's status, triggers over the past 14 days, last active time, and creation time. Click an alert to edit it. Row actions let you edit, pause, resume, or delete it.

Configure a rule

name: High tool failure rate
description: Tool calls are failing more often than expected.
trigger:
  when:
    all:
      - metric: tool.calls
        op: gte
        value: 20
      - metric: tool.errorPercent
        op: gte
        value: 5
  for: 2m
recover:
  name: Tool calls are healthy again
  description: The tool failure rate has returned to normal.
  when:
    all:
      - metric: tool.calls
        op: gte
        value: 20
      - metric: tool.errorPercent
        op: lt
        value: 2.5
  for: 2m
notify:
  - type: email
    recipients:
      - [email protected]
  - type: slack
    channel: C0123456789
FieldMeaning
nameRequired alert name, up to 120 characters.
descriptionOptional notification description, up to 500 characters.
trigger.whenRequired condition that opens the alert.
trigger.forRequired duration the trigger condition must stay true.
recover.whenRequired condition that resolves an active alert.
recover.forRequired duration the recovery condition must stay true.
recover.nameOptional recovery notification title. Defaults to the alert name followed by “resolved”.
recover.descriptionOptional recovery notification description, up to 500 characters.

Each notify entry has a type: email or slack. Email entries accept up to 20 email addresses in recipients. Omit recipients to use the alert creator's current email address while they remain a member of the organization. Explicit recipient addresses continue to work if the creator leaves the team. Slack entries use channel for a channel ID from the server's connected Slack workspace; omit it to use the connected default channel. Each type can appear once.

Names and descriptions must fit on one line. Each duration is a whole number followed by s, m, or h, from 0s to 1h. Rules are evaluated every minute: 0s triggers on the first matching observation; short durations still depend on that evaluation interval. Holds require sustained observations. Missing or stale telemetry cannot open an alert or confirm recovery, and interrupts a hold.

Conditions

A comparison contains metric, op, and a numeric value. Supported operators:

OperatorMeaning
gtGreater than
gteGreater than or equal to
ltLess than
lteLess than or equal to
eqEqual to
neNot equal to

Use all to require every child condition, or any to match at least one. Groups can be nested up to three levels, with one to eight children per group. A condition is either a comparison, an all group, or an any group. An all group is false when a child is known false; an any group is true when a child is known true. Otherwise missing data leaves the result unknown. With partial machine coverage, an observed high CPU or memory value can prove a breach, but low readings from only some machines cannot confirm recovery.

Available metrics

Request, tool, authentication, and token metrics use the last five minutes of observed traffic. Percentages range from 0 to 100; latency is in milliseconds. CPU and memory values use the maximum across active machines.

MetricValue
deployment.failedCountNumber of unresolved failed deployment attempts; available before the first running deployment.
deployment.latestOpenFailureAtMsLatest first-observed timestamp among unresolved deployment failures, in Unix milliseconds; 0 when none remain open.
cpu.busyPercentMaximum busy CPU percentage.
cpu.stealPercentMaximum CPU steal percentage.
memory.usagePercentMaximum memory usage percentage.
request.requestsMCP POST request count.
request.errorsFailed MCP POST request count.
request.errorPercentFailed MCP POST request percentage.
request.reachabilityRequestsMCP GET/POST request count.
request.reachableRequestsMCP GET/POST responses excluding 404, 5xx, and transport failures.
request.unreachablePercentMCP GET/POST 404, 5xx, and transport failure percentage.
runtime.serving1 for a serving runtime, 0 for stopped/suspended; unknown if unavailable.
tool.callsTool call count.
tool.errorsFailed tool call count.
tool.errorPercentFailed tool call percentage.
authentication.requestsCredential request count.
authentication.rejectionsRejected credential request count.
authentication.rejectionPercentRejected credential request percentage.
token.requestsToken request count.
token.errorPercentFailed token request percentage.
token.latencyP95MsToken request p95 latency.

Include a minimum request or call count alongside a percentage to avoid alerting on a small sample. Reachability alerts require real server traffic; they do not send synthetic requests or wake stopped servers.

Deployment failure alerts

Deployment failures appear in the activity feed automatically. Email and Slack notifications require an alert rule. The Deployment failed template uses:

name: Deployment failed
description: A deployment could not build or start.
trigger:
  when:
    metric: deployment.failedCount
    op: gt
    value: 0
  for: 0s
recover:
  when:
    metric: deployment.failedCount
    op: eq
    value: 0
  for: 0s
notify:
  - type: email
    recipients:
      - [email protected]

A successful deployment resolves older failures in its own production or preview branch lane. Recovery is sent once all unresolved failures counted by this rule are cleared. There is no separate account deployment-email preference.

To monitor only failures first observed after a fixed starting time, compare deployment.latestOpenFailureAtMs with that time in Unix milliseconds. Use gt for the trigger and lte for recovery, with the same numeric cutoff in both. For example, 1791979200000 represents 2026-10-14 at 12:00 UTC. Choose the actual start time when creating the rule. Existing unresolved failures before the cutoff will not trigger it. Recovery means all failures first observed after the cutoff have been superseded; older failures may remain open. Replayed callbacks preserve the original first-observed time. A failed source query is unknown and cannot confirm recovery.

Delivery

Click the delivery badges or the edit button to open the alert drawer. The delivery controls above the code editor update the channel entries in notify in the YAML. You can also edit those fields directly. The drawer's Save button saves both the rule and its delivery configuration together. Keep at least one delivery method enabled; pause the alert to stop notifications.

Email defaults to the alert creator. Search your team, select multiple members, or enter a custom email address and select Add. Selected team members are saved as email addresses, just like custom recipients. Duplicate addresses receive one message.

Connect Slack to list and search channels in your workspace. Invite the app to a private channel before selecting it. Existing connections may require reconnecting to enable channel selection. Each alert can choose its own channel.

Active means the trigger fired and recovery is pending. Running means the alert is enabled and has no active incident. Paused stops notifications until you resume it. Notifications describe the event and show observed metrics; they are sent when an alert triggers or resolves.

Admin templates and rules

Superadmins manage templates and rules at Admin → Alerts. The templates table counts distinct users with alerts created from each template. The rules table can be searched by alert, server, or organization and filtered by status and template. Rules can also select internal email/Slack delivery and a fleet, server, or organization scope. Internal notifications use the configured administrative destinations; explicit recipient addresses and channel IDs are only used by customer rules. The customer editor manages server scope through the application; delivery is editable in both the YAML and the controls above it.

On this page