> ## Documentation Index > Fetch the complete documentation index at: https://docs.horizon.prefect.io/llms.txt > Use this file to discover all available pages before exploring further. # Observability > Inspect requests, usage, performance metrics, and server logs for a deployed MCP server from one place. export const extendedObservabilityPlans = "Enterprise"; export const extendedObservabilityHistory = "up to 30 days"; export const standardObservabilityHistory = "up to 3 days"; 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](/gateway), which records request-level metadata before your code runs. That metadata is what the logs and usage analytics 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 acting user or service account, identified MCP client, request and response payloads, and gateway processing. Gateway plugins report whether they passed, modified, blocked, or errored on the request. This makes access-policy filtering and sensitive-data redaction visible in the same record as the resulting response. 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. For control over which payloads are stored, see [Data handling](/security/data-handling#payload-logging). Logs refresh live as new requests arrive, and pause when you want to study a fixed window without rows shifting underneath you. ## Usage The **Usage** page summarizes how clients use a server. It shows tool calls, unique actors, error rate, and p95 latency over the selected window, then breaks that traffic down by actor and tool. Actors include both users and service accounts, using the verified identity the gateway attached to each request. Calls that Horizon cannot attribute appear under **Unknown**. This usually means the calls were not authenticated through Horizon. These calls do not increase the unique actor count. Select an actor, including **Unknown**, to see the tools it used, or select a tool to see its callers. Prompt and resource operations appear alongside tools with their operation type, so you can investigate each kind from the same view. After selecting an actor or capability, choose **View logs** to open the request log with the same target, time range, actor, and tool filters applied. For how actor identity is established, see [Authentication](/platform/authentication). ## Performance metrics Where request logs 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. A request is one MCP JSON-RPC message, including initialization and capability-list operations. A tool call is specifically a `tools/call` request, so every tool call is an invocation while many invocations are not tool calls. * **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](/platform/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](/deployments) page. | Log type | Captures | When | Answers | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------- | | **Build logs** | The build process that turned a commit into a deployable artifact: dependency installation, entrypoint detection, inspection, and any packaging failure. | Stream while a build runs; remain available once it finishes. | Why a deploy never went live. | | **Server logs** | The running server's `stdout` and `stderr`. | After the server is deployed. | Where your own logging and uncaught errors appear. | Server logs open at the newest output and continue to refresh while you stay at the bottom of the stream. Scroll upward to load earlier output without moving your place. Floating controls jump to the deployment's first log, step backward or forward in time from what you are viewing, or return to the live stream. For what the runtime captures from your server's output, see [Compute model](/platform/compute-model). ## Programmatic access The Horizon REST API exposes request, build, and deployment runtime logs. Authenticate with a personal or service-account API key, then use the log routes in the [API reference](https://horizon.prefect.io/api/v0/docs). ## Time ranges and history Analytics views provide time-range selectors for recent windows, and 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 {standardObservabilityHistory} of metrics history; {extendedObservabilityPlans} plans extend that to {extendedObservabilityHistory}. Selecting one of the longer ranges without that plan prompts you to upgrade rather than silently returning a short window. ## Related docs See how requests are received, routed, and recorded before reaching server code. Learn how the runtime handles requests, memory, timeouts, and server logs. Find build and server logs for a specific build or deployment. Learn how the actor identity shown in usage analytics is verified.