What is Application Performance Monitoring (APM)?

What is application performance monitoring (APM)?

Application performance monitoring (APM) watches a running application from the inside. A small agent in your code records how long each request takes, which database query or external call slowed it down, and which line threw an error. You get response times, error rates, throughput and request traces for real production traffic, grouped by endpoint, service and host.

How APM works

An APM agent runs inside your application process (the JVM, Node.js, .NET, Python, Ruby) and hooks into web frameworks, database clients, HTTP clients, queue consumers and caches. Every instrumented call produces a span with a start time, an end time, a parent and tags. Spans joined together form a trace: the full path of one request from the entry point to the database and back. Aggregated traces become the dashboards engineers open during an incident.

Example: checkout feels slow. The trace for one slow request shows 80 ms in your code and 1.9 s waiting on a payment provider. Without the trace you would be guessing between the app, the database and the network.

APM vs synthetic monitoring vs RUM

• APM sits inside your code and reports real production requests with per-request detail. Best for finding which endpoint or query is slow.
• Synthetic monitoring runs scripted checks from outside, at a fixed interval and location. Best for availability and for noticing problems when no real user is online.
• Real user monitoring (RUM) runs in the browser and reports what actual visitors experienced, including device and network. Best for the user's view.

They answer different questions. APM can say the server answered in 80 ms while RUM shows a visitor on a slow mobile network waited four seconds. APM is also one part of observability, alongside logs and metrics.

What APM captures

• Rate, errors and duration per endpoint (the RED method).
• Latency percentiles such as p50, p95 and p99. See latency for why averages mislead.
• Distributed traces across services, with each hop timed.
• Database performance: slow queries, repeated queries in a loop (N+1) and connection-pool waits.
• External calls to third-party APIs and payment providers, often the slowest and hardest part to fix.
• Runtime health: memory use, garbage-collection pauses, event-loop lag.
• Exceptions with stack traces, grouped by cause with a count.

What to alert on

1. p95 latency well above its normal baseline for an endpoint.
2. Error rate above your target. Track 5xx and 4xx separately, because 4xx is often client misuse.
3. Throughput drops below the usual level, often the first sign that a load balancer lost a target.
4. External call latency rising, which your service inherits as its own delay.

Choose thresholds from your own baseline and SLOs, not from a generic number.

Common mistakes

• Alerting on averages, which hide the slow tail.
• Tracing only HTTP routes and never business steps like checkout or a batch job. Add custom spans for those.
• Sampling so aggressively that rare slow requests never show up.
• Leaving APM off in staging, so load tests teach you nothing about where the time goes.

How to roll out APM

Pick a commercial APM product or an open-source stack (traces and metrics with open standards), install the language agent, set a service name and confirm traces arrive within minutes. Then add custom spans around the operations your business cares about. For a comparison of products, see the blog guide to application performance monitoring tools.

APM and load testing

APM tells you what is happening in production. Load testing tells you what will happen at higher traffic. Run a load test against staging with APM switched on and you can see which endpoint reaches its ceiling first and why. A longer soak test with APM running also shows memory growth over time. LoadFocus load testing generates the traffic from 25 cloud regions and gives each run a pass or fail verdict on response time and error rate thresholds.

LoadFocus is not an APM and does not instrument your code. API monitoring is the outside-in complement: it checks your endpoints on a schedule (every 5 minutes on the free plan) and splits each response time into DNS, TCP connect, first byte and download, so you notice a problem even when no real user is hitting it.

FAQ

What does APM stand for?

Application performance monitoring. Some vendors also use it for application performance management, which adds tuning and remediation on top of monitoring.

What is the difference between APM and logging?

Logs record discrete events that you chose to write. APM records timing and context for every instrumented request automatically, so you can see where the time went, not only what happened.

Is APM the same as observability?

No. APM is one practice inside observability. Observability also covers logs, infrastructure metrics and the ability to ask new questions of your telemetry.

Do I still need synthetic monitoring if I have APM?

Yes. APM only sees traffic that reaches your code. A synthetic check from outside notices an outage, a failed DNS record or an expired certificate even when no request arrives.

Does APM slow my application down?

An agent adds some overhead. Most products let you control it through sampling. Measure it by running the same load test with and without the agent.