What Is Application Performance Monitoring (APM)?
Last verified on Nov 8, 2026.
Application performance monitoring (APM) measures how fast and how reliably an application serves requests, and points to the code or dependency at fault when it does not. The term covers both the practice and the tools. Microsoft's documentation, for example, describes Azure Monitor Application Insights as an APM feature of Azure Monitor.
What APM Tools Typically Cover
Vendors differ, but product documentation shows a common set. Application Insights lists:
- A dashboard and an application map, giving an overview of health and a visual of how components interact.
- Live metrics, a real-time view of activity and performance.
- Transaction search, to trace and diagnose individual transactions.
- Failures and performance views, to find errors and bottlenecks.
- A profiler, to capture performance traces of application code.
- Alerts, to notify you when something crosses a threshold.
AWS offers a similar shape through CloudWatch Application Signals, which discovers your services, clients, and dependencies, shows them as a list or a visual map, reports health based on SLOs, and lets you drill into correlated X-Ray traces. These are product examples, not a standard feature list.
What You Watch
Google's SRE book names four golden signals for a user-facing system: latency, traffic, errors, and saturation. Many APM views are variations on them. A typical question is "which endpoint's latency rose, and which downstream call did the time go to?" See golden signals and latency percentiles, and for the slowest requests the guide on tail latency.
An example of what a trace-based view lets you conclude, with made-up numbers:
POST /checkout 1840 ms
auth.verify 22 ms
cart.load 61 ms
inventory.reserve 1610 ms <- 87% of the request
db.query (SELECT ...) 1580 ms
payment.charge 140 msThe request was slow because one database query inside inventory.reserve was slow. Without a trace you would see only the 1840 ms total.
How the Data Gets There
An APM product needs the application to emit telemetry. That is instrumentation: libraries or agents that record requests, calls, and errors. OpenTelemetry is the vendor-neutral standard. Its documentation describes it as an open source framework for generating, exporting, and collecting traces, metrics, and logs, and says plainly that it is not a backend. Application Insights accepts OpenTelemetry, so the same instrumentation is not tied to one product. See the OpenTelemetry integration and the traces integration, and the entries on OpenTelemetry and distributed tracing.
APM and Observability
OpenTelemetry defines observability as the ability to understand a system from the outside by asking questions about it, including questions about novel problems, and says that requires properly instrumented code. APM is one way to put that into practice, aimed at application speed and errors. What it cannot see is what you did not instrument, and what happens outside the application, such as in a user's browser. For the browser side, see real user monitoring, and for scripted external checks, synthetic monitoring.
Alerting on What APM Shows
APM data is most useful when it feeds a small number of alerts tied to user-visible symptoms. Page on error rate and latency against an SLO rather than on every resource gauge, and read the entry on alert fatigue before you add more. When a slowdown appears gradually, the guide to latency drift covers it.
APM Data in Sazabi
Sazabi is an AI-native observability and security platform. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. The setup pages cover how to send traces and send metrics, and the reliability issues page shows what Sazabi reports from your telemetry.
Frequently Asked Questions
What does APM stand for?
APM stands for application performance monitoring: measuring how fast and how reliably an application serves requests, and finding which code or dependency is responsible when it does not.
What does an APM tool measure?
Typically request rate, error rate, and latency per service and endpoint, the dependencies each request calls, and traces of individual requests. Some add code profiling and a map of how services connect.
What is the difference between APM and observability?
Observability is the ability to understand a system from its outputs, which depends on how well it is instrumented. APM is a product category built around that kind of telemetry, with a focus on application speed and errors.
Do I need OpenTelemetry for APM?
No, but it is a common way to instrument. OpenTelemetry is a vendor-neutral standard for emitting traces, metrics, and logs, and several APM products, including Azure Application Insights, accept it.
Sources
- Azure Monitor Application Insights is an application performance monitoring (APM) feature; its parts include an application map, live metrics, transaction search, failures and performance views, alerts, and a profiler; it supports OpenTelemetry instrumentation (accessed Nov 8, 2026)
- CloudWatch Application Signals discovers services, clients, and dependencies, shows a list or visual map of services, health metrics based on SLOs, and correlated X-Ray traces (accessed Nov 8, 2026)
- OpenTelemetry is a vendor- and tool-agnostic framework for generating, exporting, and collecting traces, metrics, and logs, and is not a backend itself (accessed Nov 8, 2026)
- Observability lets you ask questions about a system from outside; the application must be instrumented to emit traces, metrics, and logs; distributed tracing follows requests across services (accessed Nov 8, 2026)
- The four golden signals are latency, traffic, errors, and saturation (accessed Nov 8, 2026)
- Sazabi ingests metrics and traces through the same intake as logs and stores them as searchable records (accessed Nov 8, 2026)