Transactions

A transaction is one request your application serves, end to end. The spans inside it are whatever your instrumentation records: your own operations from the JavaScript SDKs, fetch and XHR calls in React Native, or, on a .NET server, the request and database spans that OpenTelemetry's ASP.NET Core and Entity Framework Core instrumentation produce.

Where spans come from

The ErrorDock .NET packages emit no spans of their own. Performance for .NET comes from OpenTelemetry.

Percentiles, because averages lie

A mean response time of 180 milliseconds can conceal a P95 of three seconds. The average is dominated by the fast majority; the slow tail is where the complaints come from.

ErrorDock reports the distribution for every endpoint:

Alongside latency, each endpoint carries its error rate, and P95 is compared before and after each release.

Trace waterfalls

Each slow transaction expands into a waterfall of the spans that made it up. The point is to turn "this endpoint is slow" into "this endpoint runs the same query five times".

POST /api/meal-plan                              1,460 ms
  SELECT MealPlans             160 –   340 ms
  SELECT Recipes               340 –   550 ms
  SELECT Recipes               550 –   760 ms
  SELECT Recipes               760 –   970 ms
  SELECT Recipes               970 – 1,180 ms
  SELECT Recipes             1,180 – 1,390 ms

Five identical query spans in a row is an N+1. It is obvious from the shape in a way it never is from a number in a table, which is why the waterfall exists at all.

Database performance

There is no separate database view and no query text. Database calls appear as spans inside the request that ran them, when your instrumentation records them — Entity Framework Core's OpenTelemetry instrumentation does. That is also the form in which an N+1 is fixable: a repeated span in the waterfall shows the loop that produced it.

Regressions tied to releases

Performance is tagged by release the same way errors are. The dashboard shows each endpoint's P95 before and after a release, so the question is which deployment rather than which week.

Sampling

High-throughput applications do not need every transaction stored to get a reliable distribution. ErrorDock uses head sampling, and the rate is set in the dashboard rather than in your code. Errors are never sampled — an exception that only happens once is exactly the one you need.

Not built

A database-query view or query text, web vitals, page-load transactions and profiling.

Related

• Releases
• Sessions
• Product Health: feature health and priorities