Alerts

Anypoint Monitoring alerts watch one metric on one CloudHub 2.0 app or API instance and notify by email or Slack. The MCP tools and anc alerts list, read, create, change, enable, disable and delete them.

Undocumented API

These tools call the observability API that the Monitoring UI uses (/observability/api/v1/organizations/{orgId}/alerts). It is not publicly documented and can change without notice. When an organization or token cannot reach it (HTTP 404 or 403), the tools report the family as unsupported instead of returning "no alerts". Runtime Manager event alerts (/armui/api/v1/alerts) are read only. Right after a change the alert list and a read of one alert can disagree; the tools trust the list for deletion.

Read

list_alerts({ "environment": "Sandbox", "entityType": "application" })
get_alert({ "id": "<alert id>" })
get_api_alerts({ "apiName": "orders-api", "environment": "Sandbox" })   // API Manager and Monitoring alerts

Every alert is normalized to:

Field	Meaning
id, source	Alert ID; monitoring or runtime-manager
name, enabled	As stored. Names are not unique
severity	One label set for every family: LOW, MEDIUM, HIGH, CRITICAL. Monitoring stores 0-3 (also shown as severityLevel); Runtime Manager and older alerts use words such as INFO or warning, mapped to the same labels
status	PENDING (a change in progress) or ACTIVE
state	OK or ALERTING
entity	type (application, api, server), name, deploymentType (CLOUDHUB, CLOUDHUB2, RTF, HYBRID), environment
condition	metric, operator, threshold and unit (percent for cpu and memory), windowMinutes; for Runtime Manager alerts, event (for example deployment-failed)
recipientCount, slackChannels	Recipients are masked to counts. revealRecipients: true (CLI --reveal) adds the recipients and their recipientDomains; domains alone can identify clients, so they are hidden otherwise

Deleted alerts do not appear: the platform drops them from the list, so there is no DELETED filter.

Runtime Manager event alerts are read from condition{type, resourceType, resources[]} (the target is the resources, mc-application meaning an app) and actions[]{type, userIds[], emails[], subject, content} (the recipient count is user IDs plus addresses), with conditionType, isSystem and productName passed through.

Metrics

Metric	Target	Unit	Aggregation
cpu_utilization, memory_utilization	app	percent	average
thread_count	app	count	average
message_count, message_error_count	app	count	sum
message_response_time	app	ms	average
api_request_count	API instance	count	sum
api_response_time	API instance	ms	average
api_response_code_count	API instance	count	sum; needs apiFilters.responseCodes
api_policy_violation_count	API instance	count	sum; needs apiFilters.policies

Give a percent threshold as a percentage (90); it is stored as a fraction (0.9). Counts are whole numbers. durationMinutes (1 to 60) is how long the condition must hold.

Create

create_alert({
  "environment": "Sandbox",
  "name": "orders cpu",
  "target": { "app": "orders-sapi" },
  "metric": "cpu_utilization",
  "operator": "GREATER_THAN",
  "threshold": 90,
  "durationMinutes": 10,
  "severity": 1,
  "notifications": [
    { "type": "EMAIL", "recipients": ["ops@example.com"], "subject": "CPU high", "message": "CPU is high" }
  ]
})

• The target is resolved from CloudHub 2.0 ({ "app": ... }) or API Manager ({ "apiInstanceId": ... }).
• Notifications are explicit. There are no default recipients, and at least one is required.
• The alert is created disabled unless enabled: true.
• The preview shows the exact payload and recipients, and warns when a recipient is outside your own email domain (your address is never shown).
• An alert with the same name on the same target is refused, with its existingId, unless allowDuplicate: true.
• A new alert is PENDING until the platform provisions it.

Change, enable, disable, delete

• update_alert({ id, patch }) changes name, severity, enabled, operator, threshold, durationMinutes or notifications (replaced as a whole). The platform needs the full alert, so the tool reads it, merges the patch and sends it whole, keeping every writable field of the existing alert (tags, alertOn, unknown notification fields) and dropping only read-only ones (status, state, timestamps). Metric and target cannot change; create a new alert. A notification change is detected on the full notification bodies; the preview shows it masked, with differs naming what changed (recipients, subject, messageTemplate, channelId).
• Platform error text is sanitized before it is returned or printed: email addresses keep only their domain, and token-like values are masked.
• set_alert_enabled({ id, enabled }) switches an alert on or off.
• The platform accepts a change (HTTP 202) and applies it asynchronously. After sending it, the tools read the alert from the list once and report accepted, verified and status: "Updated" only when the list shows the alert ACTIVE with the new values; otherwise PENDING or UNVERIFIED with a hint to check again.
• A PENDING alert cannot be changed; the tool refuses with a retry-later message.
• delete_alert({ id, expectedName }) is bound like delete_app: preview first, then confirm: true with the name from the preview. The alert is read from the list first: a PENDING alert (a change in progress) is refused with retry later, and the dry run warns. The platform can answer 404 for such an alert while still listing it, so a 404 alone never counts as deleted. After the delete, the result is verified from the list, because a read of the single alert can keep answering ACTIVE: GONE with verifiedAbsent: true once the list no longer shows it (also when DELETE answers 404 and the list agrees), otherwise accepted with PENDING or ACTIVE, never "deleted". The list is read narrowed by environment and name; if it is still longer than the tools read (2,000 alerts), absence proves nothing and the result is UNVERIFIED.
• Severity is given as 0-3 or as LOW, MEDIUM, HIGH, CRITICAL.
• For an API target, the create preview names only the instance ID you passed; the API name and endpoint resolved from API Manager are sent but not printed.

Safety

Every write previews by default and needs confirm: true. The alert's own environment decides whether production confirmation applies: confirmProduction: true, or a user-level pre-approval. "all-mutating" covers create_alert, update_alert and set_alert_enabled; delete_alert is covered only when named.

CLI

anc alerts list --env Sandbox
anc alerts get <id> --reveal
anc alerts create -e Sandbox --name "orders cpu" --app orders-sapi --metric cpu_utilization \
  --operator GREATER_THAN --threshold 90 --duration 10 --severity 1 \
  --email ops@example.com --subject "CPU high" --message "CPU is high" --dry-run
anc alerts update <id> --threshold 95
anc alerts disable <id>
anc alerts delete <id> --confirm "orders cpu"

Production writes ask for the typed phrase unless --force or a pre-approval covers them; anc alerts delete in production needs --allow-production or a pre-approval that names delete_alert.