APM overview

Errorgap APM records how long your application spends serving requests and running background jobs, then surfaces throughput, latency, and error health on the Performance page of each project. It answers which routes are slow, where the time goes, and whether the latest release made things better or worse.

What APM captures

Every recorded unit of work is a transaction, optionally broken down into spans:

• Transactions — one per request or job: the route or job class, status code, total duration, and component timings such as database, view, and external time.
• Spans — child operations inside a transaction, most commonly individual database queries with normalized SQL, duration, and the source location that issued them.

SQL in spans is normalized — literal values are replaced with placeholders — so identical queries group together and no customer data is stored in query text.

Web and job transactions

Web transactions record the HTTP method, a normalized route pattern, and the response status, so traffic groups by route rather than by individual URL. Background jobs record the job class and queue instead of HTTP fields. Both kinds carry an environment label, letting you compare production against staging.

The Performance page

The Performance page filters by time range, from the last hour to the last 90 days, and by environment. It is organized into four views:

• Summary — Apdex score, request rate, mean latency, and error rate, each with a time-series chart.
• Routes — per-route throughput, p50 and p95 latency, status breakdown, and error rate, with a detail view showing the slowest recent events and where their time went.
• Queries — database queries aggregated by normalized SQL, for finding the statements that dominate database time.
• Jobs — background job timing aggregated by class.

Routes tab

Start with Routes when user-facing latency changes. Sort by traffic, p95 latency, or error rate to find endpoints that combine impact with poor behavior. Open a route detail to see trend charts, time breakdown, and the slowest recent events for that route.

• Use p50 to understand the typical user experience.
• Use p95 to find tail latency that only affects some requests.
• Use status breakdowns to separate slow success responses from failing requests.
• Open slowest events when one endpoint has outliers that need request-level evidence.

Queries tab

The Queries tab groups database spans by normalized SQL. Use it to find statements that consume the most total time or appear frequently enough to matter. A query with moderate latency can still dominate performance if it runs on every request.

• Look for missing indexes when one query has high p95 latency.
• Look for N+1 behavior when a query has a high count for one route.
• Use source file and function hints to find the code path that issued the query.

Jobs tab

The Jobs tab groups background work by job class. Use it when queue latency, worker load, or retry storms may be affecting customers indirectly. Compare job timing with logs and errors from the same time range before changing worker capacity.

Apdex

Apdex condenses response times into a single satisfaction score using a threshold of 500 milliseconds. Requests faster than the threshold are satisfied, requests up to four times the threshold are tolerating, and anything slower is frustrated. The score weights tolerating requests at half value, and the Performance page labels it Healthy at 0.9 or above, Fair at 0.7 or above, and Degraded below that.

Filters and comparisons

Use the time-range control to match the question you are asking. The last hour is useful during an incident, 24 hours is useful after a deploy, and 7 to 90 days is better for baseline work. Use the environment filter before comparing staging and production, because staging traffic usually has different volume and shape.

Next steps

• Instrument your app to start recording transactions.
• Watch the Routes view after each release for latency regressions.
• Use the Queries view to find database statements worth indexing or caching.