Observability

Once a server is live, the question shifts from how to deploy it to what it is doing in production. Horizon answers that from the server’s own pages: which clients are calling it, which tools they invoke, how long requests take, who is using the server, and what the server printed while it ran. These views share one source of truth. Every MCP request passes through the gateway, which records request-level metadata before your code runs. That metadata is what the logs, session views, user analytics, and performance charts all read from, so the same request shows up consistently wherever you look at it.

​

Request logs

The Logs page is the request-by-request record of traffic to a server. Each entry is one MCP request: the method that was called, whether it was a standard JSON-RPC call such as tools/list or a specific tool invocation, the status the gateway returned, and when it happened. A histogram above the list shows request frequency over the selected time range, so a spike or a gap is visible before you read a single row. Selecting a request opens its full detail, including the request and response payloads. This is the first place to look when a client reports that a call failed: you can confirm whether the request reached the gateway, how it was routed, and whether it was accepted or rejected before assuming the problem is in server code. Filter to errors only to narrow a noisy stream down to the requests that did not succeed. Logs refresh live as new requests arrive, and pause when you want to study a fixed window without rows shifting underneath you.

​

Sessions

An MCP client that initializes a session receives an mcp-session-id and sends it on follow-up requests, so a session is the unit that ties a client’s related calls together. The Sessions page lists those sessions over time. Each row carries the session identifier, the user behind it, which client it came from such as Claude, Cursor, or ChatGPT, its start and most recent activity, and how many tool calls it has made, so a long-running or unusually busy session stands out from routine traffic. Selecting a session opens its full metadata in a side panel, including the client name, version, and protocol version it negotiated. Use sessions when you need to follow one client’s activity as a unit rather than as scattered individual requests, such as understanding the shape of a single agent’s interaction with the server. For how Horizon issues and preserves session routing at the request layer, see Gateway.

​

Users

The Users page answers who is actually using a server rather than how many requests it served. It charts active users over the selected window alongside the cumulative count of new users, which separates a server that a few people use heavily from one that is steadily reaching more of the organization. The list pages through individual users, and selecting one opens that user’s profile and activity. The identity shown here is the verified caller identity the gateway attached to the request, so it reflects the same authentication that controls access. For how that identity is established, see Authentication.

​

Performance metrics

Where logs and sessions describe individual traffic, the Observability page describes the server’s behavior in aggregate. Three charts cover the questions you ask when a server feels slow or unhealthy:

• Duration shows request latency as a distribution, including average, p50, p95, and p99, so a tail of slow requests is visible even when the average looks fine.
• Invocations shows total requests over time, which is how you confirm whether a latency change tracks a change in load.
• Memory shows memory usage and allocation, which is where you look when a server is being terminated for exceeding its limit rather than returning errors.

For what those limits are and how the runtime enforces them, see Compute model.

​

Server logs

Request logs and metrics describe traffic from the outside. The logs the server itself produced live with the deployment that produced them, reached from a build or deployment on the Deployments page. For what the runtime captures from your server’s output, see Compute model.

​

Time ranges and history

Every analytics view shares a time-range selector covering recent windows from the last five minutes through the last several days, and the live views refresh on their own so a dashboard left open keeps current. On the Observability performance charts, the longest ranges are plan-gated. Standard plans retain of metrics history; plans extend that to . Selecting one of the longer ranges without that plan prompts you to upgrade rather than silently returning a short window.

​

Related docs