> ## Documentation Index > Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt > Use this file to discover all available pages before exploring further. # Alerts > What the MCP Manager Alerts page surfaces — the error, warning, and info events it raises, what triggers each one, what an alert record contains, and how alerts differ from logs and reporting. 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](https://app.mcpmanager.ai/settings/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](#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](/features/viewing-logs), and [Reporting](/features/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](#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](#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. | Code | Severity | What triggers it | | ------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------- | | `warning.gateway.policy_triggered.tool_response` | Warning | A policy rule on a gateway flagged a tool response while enforcing your configured policy. | | `warning.gateway.rule_engine_misconfigured` | Warning | A policy references a rule engine whose URL is missing or invalid, so the engine cannot be reached. | | `warning.gateway.rule_engine_error_verdict` | Warning | A configured rule engine failed at request time (for example, returned an error or timed out). | | `error.inbound_server.oauth_callback_failed` | Error | The OAuth token exchange with a connected server failed during the authentication callback. | 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. | Code | What it means | Was the engine reached? | | ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- | | `warning.gateway.rule_engine_error_verdict` | The engine was **unreachable or errored**. No verdict was returned. The block or allow you see came from the rule's [failure mode](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails) configuration, not from the engine's decision. | **No** | | `warning.gateway.policy_triggered.tool_response` | The engine **was reached and returned a verdict** (pass, modify, or block). The outcome is the engine's actual decision. | **Yes** | 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. ### Navigating from an alert 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](https://app.mcpmanager.ai/settings/integrations) 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](https://app.mcpmanager.ai/settings/people)), the **Alerting** group contains one capability: | Capability | What it allows | | ------------------ | ---------------------------------------------------------- | | **See all alerts** | View all alerts in the workspace and open the Alerts page. | 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 The full per-request record behind an alert, with scoped views and export. Workspace-wide trend charts for activity, performance, and error rates.