app-performance-monitoringlisted

## Overview APM answers "why is this slow?" with data: which transactions are slow, which spans dominate, which database queries drag, and how performance trends across releases. This skill covers instrumenting applications for performance visibility and using that data to find and fix real bottlenecks — independent of any specific APM vendor. ## When to use - Finding why an endpoint or page load is slow - Setting up transaction tracing and span instrumentation - Identifying N+1 queries, slow serialization, or chatty service calls - Tracking performance across releases (did v2.1 get slower?) - Deciding what to instrument with custom spans vs automatic ## Core concepts **Transactions and spans.** A transaction = one unit of work (an HTTP request, a background job, a page load). Spans = its decomposed steps (DB query, cache call, external API, template render). Automatic instrumentation covers frameworks and drivers; custom spans mark your business logic ("compute recommendations"). The trace waterfall shows exactly where time goes — optimize the longest bars first. **Measure percentiles, not averages.** Averages hide the pain: p50 tells you the typical experience, p95/p99 the bad one users actually complain about. Track latency as a distribution; alert on p99, optimize the spans that dominate p99 traces. **Apdex / satisfaction framing.** Translate latency into user experience: what fraction of requests are "satisfying" (< T), "tolerable", "frustrating"? It focuses optim