Skip to main content
The Alerts page in MCP Manager is the workspace-wide feed of notable events that an administrator should know about — authentication failures on a connected server, and the outcomes of policy rule engines configured on your gateways. Open it from the Alerts link in the left-hand navigation at Alerts. Each alert is a stored record you can open, read, and use to jump straight to the server, gateway, policy, or connection it concerns.
If you don’t see an Alerts link in your left-hand navigation, your role doesn’t have the See all alerts capability. Access to the Alerts page — and whether the link appears at all — is controlled by that capability. Ask whoever manages roles in your workspace to grant it. See Who can see alerts.
Alerts are in-app only today. MCP Manager does not yet send alerts by email, Slack, or webhook — there is no proactive notification. To learn about a new alert, open the Alerts page. Treat it as a feed you check, not a channel that pages you.

​
How alerts differ from logs and reporting

The Alerts page, Viewing Logs, and Reporting draw on the same gateway activity but answer different questions:
  • Logs capture every individual request and response passing through a gateway — the complete per-message record.
  • Reporting aggregates that activity into trend charts — what was called, by whom, how fast.
  • Alerts call out a small set of notable events — things that failed or that a policy flagged — that warrant an administrator’s attention.
An alert is the exception worth surfacing; a log is the full transcript. When an alert fires, the logs are where you find the surrounding request detail.

​
What an alert record contains

Every alert is a stored record with the same shape, designed so you can start diagnosing the problem from the alert alone:
  • A subject and message — a plain-language summary of what happened (for example, “Failed to refresh features for …”).
  • A code — a machine-readable identifier in the form type.category.subcategory, where type is one of error, warning, or info. The code groups the alert by severity and source. See What triggers an alert.
  • A debug context — the technical detail an engineer would need to diagnose the cause. For a failed HTTP call this includes the response status code, the response headers, and the response body. Long values (headers and bodies) are truncated in the panel and offer a copy button for the full value.
  • Related-resource links — navigation shortcuts to the server, identity, gateway, gateway-server assignment, policy, rule engine, and connection involved (see Navigating from an alert).
Alerts do not have a resolved state. An alert is a record that an event occurred; MCP Manager does not track whether you have acted on it, and there is no “mark as resolved” action. Old alerts remain in the list until removed.

​
What triggers an alert

MCP Manager raises an alert for the following events. Each row shows the alert’s code and what causes it. Warnings come from gateway policy enforcement; errors come from connected-server failures. A few behaviors are worth calling out explicitly:
  • A rule-engine error does not block the request. When a rule engine fails at runtime (warning.gateway.rule_engine_error_verdict), MCP Manager records the alert but does not automatically block the call — the policy’s own failure mode decides whether the request passes or is blocked.
  • Engine alerts are deduplicated for 30 minutes. To prevent a misconfigured or failing engine from flooding the feed, MCP Manager raises at most one rule_engine_misconfigured and one rule_engine_error_verdict alert per engine per 30-minute window. Policy-trigger and OAuth-callback alerts are not deduplicated and are recorded each time they occur.
  • Alerts are workspace-scoped. The Alerts page shows alerts for the whole workspace (organization), not per-user. There are no on-page filters to scope by gateway, server, or user.

​
Understanding rule-engine alert codes

The two rule-engine warning codes represent fundamentally different states — one means the engine failed to respond, the other means it responded and fired a rule. They can look similar in the alert panel, especially when a failure mode block label appears alongside a block action. The failure mode block label in the alert detail panel is a confirmation that the rule’s failure mode is configured to block — it is not a signal that the engine evaluated the content and decided to block it. When you see this label on a rule_engine_error_verdict alert, it means the engine was down or errored and the failure mode closed the call. When you see it on a policy_triggered alert, the engine was healthy and the block was its verdict. Practical test: if you’re investigating a block and aren’t sure whether your rule engine actually fired or was simply unreachable, check the alert code first. rule_engine_error_verdict → diagnose connectivity or the engine’s health. policy_triggered.tool_response → review the engine’s policy configuration.

​
Viewing and navigating alerts

The Alerts page lists alerts in a paginated table, ordered by when they were created, with the most recent at the top. Each row shows the alert’s subject and message and its creation date. Selecting a row opens a detail panel with the full message, the debug context, and the related-resource links. The table loads 50 alerts per page by default; you can switch the page size to 100 or 250. Pagination preferences are remembered for this page. The alert detail panel links to the resources the alert concerns, so you can go straight from the event to the thing that caused it. Depending on the alert, the panel offers links to:
  • the MCP server involved,
  • the connected-server identity that failed,
  • the gateway that processed or blocked the call,
  • the gateway-to-server assignment,
  • the policy whose rule triggered (opens the gateway’s rules),
  • the rule engine referenced (opens the Rule Engines list, where you can find the engine by its ID — there is no per-engine deep link yet), and
  • the connection involved, along with the user who established it (shown by name and email).
A link appears only when that resource is attached to the alert. Each alert also has its own URL, so you can share or bookmark a specific alert.

​
Who can see alerts

Access to the Alerts page is controlled by a single capability. Under the Capabilities tab when managing a role (in People), the Alerting group contains one capability: When a user’s role has See all alerts, the Alerts link appears in their left-hand navigation and they can open every alert; when their role does not, the link is hidden and the page is unavailable to them. Capabilities are assigned per role and are fully configurable — including on any custom roles you create — so whether a given person has access depends on the capabilities granted to their role, not on any fixed role name. Because alert debug context can include request and response data, grant See all alerts only to the roles that should see that detail.

​
Further reading

Viewing logs

The full per-request record behind an alert, with scoped views and export.

Reporting

Workspace-wide trend charts for activity, performance, and error rates.