What Is Application Performance Monitoring (APM)?

When your website is slow or returning errors, uptime monitoring tells you that something is wrong. Application Performance Monitoring (APM) tells you why — pinpointing slow database queries, inefficient code paths, memory leaks, and external API latency at the function level.

APM and uptime monitoring serve different purposes, and the most reliable production systems use both.

What APM Monitors

APM tools instrument your application code (typically via an agent or SDK) to capture:

Request Tracing

Distributed tracing follows a single request through your entire stack — from the initial HTTP request, through your application code, to database queries, cache lookups, and external API calls, all the way to the response.

A trace shows you exactly where time is spent:

GET /api/orders → 847ms total
  └── Auth middleware: 12ms
  └── Database query (orders): 523ms ← slow!
  └── Database query (user): 28ms
  └── Cache lookup: 3ms
  └── Response serialization: 281ms ← also slow

This level of detail is impossible from external monitoring alone.

Error Tracking

APM tools capture application errors with full stack traces, grouping similar errors together and tracking their frequency over time. You can see exactly which line of code is throwing an exception and how often.

Performance Metrics

Key metrics captured by APM:

• Apdex score — user satisfaction index based on response time targets
• Throughput — requests per minute/second
• Error rate — percentage of requests returning errors
• Response time distribution — percentiles (p50, p95, p99) showing typical and worst-case performance
• CPU and memory usage at the process level

Database Performance

APM tools typically have specific instrumentation for databases, showing:

• Slow queries (queries exceeding a threshold)
• N+1 query patterns (ORM inefficiencies)
• Query frequency and aggregate time

Database performance is one of the most common causes of application slowness.

External Service Calls

APM instruments HTTP calls to external services, showing latency and error rates for each dependency. This helps you distinguish between your application being slow and a third-party API being slow — critical for monitoring third-party API dependencies.

APM vs. Uptime Monitoring: The Key Difference

These two monitoring types answer fundamentally different questions:

Uptime monitoring is your first line of defence — it detects when users can't reach your service, from the user's perspective. APM is your diagnostic tool — it tells you what's happening inside the application.

A complete monitoring strategy requires both. External uptime monitoring from Domain Monitor gives you the user-perspective signal; APM gives you the diagnosis capability.

How APM Integrates with Uptime Monitoring

In practice, the workflow looks like this:

1. External uptime monitor fires — the site returned a 500 error twice in a row
2. Engineer investigates — opens APM dashboard, sees error rate spiked at the same time
3. Traces show the cause — a database query for the checkout flow is timing out
4. Metrics confirm — database connection pool is at 95% capacity
5. Fix deployed — connection pool limit increased, slow query optimised
6. Uptime monitor recovers — external checks return to green

Without uptime monitoring, step 1 might not happen for hours. Without APM, step 3 might take much longer.

Popular APM Tools

When Do You Need APM?

APM becomes valuable when:

• Application performance is user-facing: Slow responses hurt conversion and retention
• You have complex dependencies: Databases, caches, multiple microservices, external APIs
• Debugging production issues is painful: You're flying blind without code-level insight
• You're scaling: Performance issues at low traffic become critical at high traffic

For small, simple applications, APM may be overkill. Start with uptime monitoring and error tracking (Sentry or similar); add full APM when complexity and scale justify it.

APM and the Observability Stack

APM sits within the broader observability stack:

• Metrics — what's happening (Prometheus, CloudWatch)
• Logs — what happened (ELK, Loki)
• Traces — why it happened (APM)
• External availability — can users reach you (Domain Monitor)

Each layer provides different signal. Together they give you complete visibility into your system's behaviour.

Performance Budgets and SLOs

APM data feeds into performance SLOs. For example:

• p95 response time < 500ms — 95% of requests must complete within 500ms
• Error rate < 0.1% — fewer than 1 in 1000 requests should return 5xx errors

These targets tie directly to error budgets and help you make data-driven decisions about when to prioritise reliability work over feature development.

Start with the external availability layer — set up uptime monitoring at Domain Monitor before adding APM.

Related Articles

• "What Are Core Web Vitals and How Do They Relate to Monitoring?"
• "What Is Network Latency and How Does It Affect Website Performance?"
• "What Is an Error Budget? Balancing Reliability and Development Speed"