Reference · Cloud
Azure MCP monitoring
Azure Monitor is excellent at what it does: tracking CPU, memory, request counts, and HTTP error rates for services running on Azure infrastructure. It is not designed to verify that a JSON-RPC endpoint is responding correctly to MCP protocol messages, that the tool registry is returning the expected schema, or that agents connecting from outside Azure's network can actually reach the endpoint. For MCP servers hosted on Azure, you need both.
TL;DR
Azure Monitor and Application Insights cover internal performance — is the container healthy, are requests processing, is latency within range? AliveMCP covers external protocol availability — can agents actually connect, handshake, and use the tools? The two are complementary, not competing. Use Azure Monitor for infrastructure and application-layer observability; use AliveMCP for MCP-protocol availability monitoring from the agent's perspective. Join the waitlist to add protocol monitoring alongside your Azure infrastructure metrics.
Azure deployment patterns for MCP servers
MCP servers run on Azure using several different services, each with different monitoring characteristics.
Azure Container Apps
The most common production deployment path for MCP servers on Azure. Container Apps provides managed Kubernetes-style hosting with built-in HTTP ingress, automatic HTTPS, and scale-to-zero. The managed ingress terminates TLS and handles the external-facing HTTPS endpoint. Azure Monitor integration is built in: you get request count, latency distribution, HTTP 2xx/4xx/5xx breakdowns, and container health metrics without additional configuration.
Monitoring gap: Azure Container Apps health probes (livenessProbe, readinessProbe) are HTTP-level — typically a GET to /health returning 200. A container that's healthy by the liveness probe but broken at the MCP router level will continue receiving traffic. The Container Apps platform will not restart or remove it because the HTTP health check passes.
Azure App Service
App Service is easier to configure than Container Apps for teams without container expertise. It supports Node.js, Python, and .NET runtimes directly, making it a natural fit for MCP servers built with the official SDKs. App Service Health Check (not the same as App Service Monitoring) sends periodic HTTP requests to a configurable path and removes unhealthy instances from the load balancer rotation. Again: HTTP-level, not MCP-protocol-level.
Azure Functions (HTTP trigger)
Serverless MCP servers using Azure Functions with HTTP triggers are economical for low-traffic endpoints. Cold start is the primary operational concern: a function that hasn't been invoked recently will take 200–2000ms to initialize on the first call. For an MCP client whose protocol timeout is 10–15 seconds, this is usually fine. For latency-sensitive agent workflows, cold starts can visibly degrade the agent turn. Azure Monitor's Cold Start Count metric tracks this, but doesn't tell you whether the cold-started function completed the MCP handshake correctly.
Azure Container Instances
ACI is typically used for development, testing, and batch workloads — not production MCP serving. It has minimal built-in monitoring (CPU and memory only) and no automatic load balancing or health-check-based traffic management. For production MCP servers, Container Apps or App Service is the appropriate choice.
What Azure Monitor covers
Azure Monitor, with Application Insights instrumentation, covers:
- Infrastructure metrics
- CPU utilization, memory usage, container restarts, scale-out events. These tell you whether the underlying compute is healthy, not whether the MCP protocol layer is healthy. A container that's at 90% memory but still responding to HTTP requests will show as healthy in infrastructure metrics but may be degrading MCP tool responses due to garbage collection pauses.
- HTTP request metrics
- Request count, response time (average and percentiles), HTTP status code breakdown (2xx/4xx/5xx). These are measured at the load balancer or ingress controller, which sees HTTP envelopes. An MCP request that returns HTTP 200 with a malformed JSON-RPC body is indistinguishable from a correct response in the HTTP metrics layer.
- Application Insights custom traces
- If you instrument your MCP server code with the Application Insights SDK (or the OpenTelemetry exporter that sends to Application Insights), you can add custom events for MCP-specific operations: initialization success/failure, tools-list response time, per-tool call latency and error rate. This is valuable deep instrumentation — but it requires modifying every version of your MCP server, and it measures from inside your code, not from the external caller's perspective.
- Availability tests (Application Insights)
- Application Insights supports URL ping tests and multi-step web tests. A URL ping test can hit your MCP endpoint's health URL and alert on non-200 responses. A multi-step web test could theoretically be written to POST a JSON-RPC request and check the response body. This is the closest Azure Monitor gets to MCP-protocol monitoring — but it requires custom scripting, doesn't have built-in MCP handshake awareness, and runs from Azure's own infrastructure (not from the external internet paths your agents use).
What Azure Monitor misses for MCP
The JSON-RPC protocol layer
Azure Monitor sees TCP connections and HTTP status codes. It doesn't inspect JSON-RPC payloads. A successful HTTP 200 response to a POST at /mcp can contain:
- A valid JSON-RPC success response — the server is working correctly
- A JSON-RPC error response (e.g.,
-32601 Method not found) — the server is running but the MCP router is broken - A malformed JSON body — the server is running but a serializer is broken
- An empty body — a middleware layer swallowed the response
All four cases look identical in Azure Monitor's HTTP metrics: one successful 200 request, normal latency, no error in the HTTP layer. From an agent's perspective, the first case works and the other three fail. The gap between HTTP metrics and protocol metrics is where most MCP-specific failures live.
External availability from the agent's network
Azure Monitor measures from within Azure's network. Your Application Insights availability tests run from Azure's probe nodes, not from the public internet paths that external agents traverse. A DNS misconfiguration that affects agents on Cloudflare's network, a routing issue on a specific ISP's path, or a CDN edge node misconfiguration — none of these will show up in Azure Monitor availability tests that probe from inside Azure.
This is the structural blind spot of all cloud-internal monitoring: the vantage point is the cloud, not the client. An agent running on a developer's laptop in a different region may see a completely different availability picture than Azure Monitor reports.
tools/list schema completeness
Even if your MCP endpoint responds successfully to the initialize request, a broken tool registry connection might cause tools/list to return an empty array or a partial list. From HTTP metrics: one 200 response. From the agent's perspective: none of the expected tools are available. This class of failure is undetectable by any HTTP-level monitor, including Azure Monitor's availability tests.
Third-party MCP dependencies
If your Azure-hosted application uses third-party MCP servers (external APIs, partner integrations, registry MCPs), Azure Monitor covers only your own infrastructure. The third-party endpoints have no Azure Monitor coverage. If a third-party MCP fails, you'll only know when your agents start returning degraded responses — unless you're monitoring those endpoints externally.
Using Azure Monitor and AliveMCP together
The two monitoring layers answer different questions:
| Question | Azure Monitor | AliveMCP |
|---|---|---|
| Is the container running? | Yes (liveness probe) | Not the primary signal |
| Is the HTTP request processing? | Yes (request metrics) | Yes (transport layer) |
| Is the MCP handshake completing? | Only with custom scripting | Yes (native protocol check) |
| Is tools/list returning the right tools? | No | Yes (tools/list verification) |
| Can external agents reach the endpoint? | Partially (Azure-internal probes) | Yes (external public internet probes) |
| What's my 30-day availability? | Requires custom query | Built-in dashboard |
The recommended pattern is to keep Azure Monitor for infrastructure and application performance alerting (CPU spikes, memory pressure, error rate on your own application logic) and add AliveMCP for external protocol availability monitoring. The two alert pipelines handle different failure modes and don't duplicate each other.
Configure Azure Monitor alerts to fire to your Slack/PagerDuty on infrastructure-level events (container restart loop, sustained high CPU, high 5xx rate). Configure AliveMCP alerts to fire on protocol-level events (three consecutive initialization failures, empty tools/list, TLS certificate expiry). Both flow to the same on-call channel but with distinct signal meaning.
Azure-specific notes
Private endpoints and VNet integration
Azure Container Apps and App Service support VNet integration and private endpoints. An MCP server with a private endpoint has no public internet address — only resources within the VNet can connect. External monitoring services (including AliveMCP) cannot reach private endpoints. For private MCP servers, monitoring requires a probe running inside the same VNet, or an internal monitoring agent. AliveMCP's Team tier includes documentation for private network monitoring configurations.
Managed certificates on Azure
Azure Container Apps and App Service provide managed TLS certificates for custom domains — certificates are provisioned and rotated automatically by Azure. The certificate expiry risk is lower than with Let's Encrypt-on-VMs setups. However, if a certificate renewal fails (due to a DNS propagation issue or domain validation failure), the failure happens silently in the Azure portal without user notification. External certificate monitoring (which AliveMCP provides alongside protocol monitoring) catches this before the cert expires.
Related questions
Does Application Insights automatically trace MCP tool calls?
Not out of the box. Application Insights traces HTTP requests automatically if you use the SDK, but MCP tool calls are JSON-RPC messages over HTTP POST — Application Insights will trace the HTTP envelope (a POST to /mcp with some latency) but not the individual tool calls inside it. To trace per-tool-call latency and error rate, you need to add custom Application Insights events in your MCP server's tool handler code.
Can I use Azure Monitor Workbooks to build an MCP availability dashboard?
Yes, if you've instrumented your MCP server with custom Application Insights events for each protocol step. You'd log a custom event on each initialize and tools/list call with success/failure and latency fields, then build a Workbook that queries those events. This is more effort than a purpose-built MCP monitor but gives you full control over the dashboard within the Azure ecosystem.
How do I monitor an MCP server on Azure Container Apps with scale-to-zero?
Scale-to-zero means the container may be suspended when there are no incoming requests. An external probe (like AliveMCP's 60-second probe) acts as a keep-alive — the probe's regular requests prevent the container from scaling to zero during low-traffic periods. This has a side benefit for cold-start latency: the container is usually warm when real agent requests arrive. If you explicitly want scale-to-zero, be aware that the probe will incur the cost of keeping the container alive.