Average Transaction Duration by App Name: Choosing the Right NRQL Query

The baseline query is simple:

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago

Run this in the New Relic query builder and you get one average transaction duration, in seconds, for every application that reported data in the last 24 hours. The real decision is not whether this query works. It is which variant you need: a single number per app, a trend line across the day, a tail-latency view, or a per-endpoint breakdown. This guide walks through those choices so you land on the right query the first time.

Introduction

"Average transaction duration by app" sounds like one question. In practice it is at least five, and each has a different NRQL answer. A platform engineer comparing services after a deploy wants a flat, per-app number. An SRE investigating a latency spike wants that number bucketed over time. A team chasing slow endpoints wants the average split by transaction name, not just by app.

NRQL, the query language behind New Relic, handles all of these with one core syntax. New Relic's introduction to NRQL describes it as a SQL-like language for querying all of your telemetry in one place, and that is exactly what makes this decision manageable: you change clauses, not tools.

If you are not yet collecting Transaction events, none of these queries have anything to work with. New Relic application monitoring instruments your services and produces the Transaction events, the duration attribute, and the appName field these queries rely on as soon as an agent is installed. From there, the only decision left is which shape of answer you need.

Key Takeaways

The core query is SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago.
The duration attribute is measured in seconds. Multiply by 1000 if you want milliseconds.
Add TIMESERIES for a trend, percentile() for tail latency, and LIMIT when you have more than 10 apps.
Apply EXTRAPOLATE when your agents sample traffic so results reflect all transactions.
Every variant in this guide can be saved as a dashboard widget or turned into an alert condition.

Decision criteria

Four factors determine which version of the query you should run.

Aggregation function. average(duration) answers "what is typical?" Averages hide outliers, so if a handful of slow requests matter to you, percentile(duration, 95, 99) exposes the tail. If you want the full distribution rather than a summary statistic, histogram(duration, 20) buckets durations so you can see where requests cluster.

Time shape. SINCE 1 day ago with no other clause collapses the whole day into one number per app. Add TIMESERIES and NRQL splits the day into buckets, which is what you want for spotting regressions or correlating latency with deploys.

Facet granularity. FACET appName gives one row per application. FACET appName, name gives one row per endpoint within each application, which is how you find the specific transaction dragging an app's average up.

Data completeness. APM agents can sample transaction data under high throughput. Without correction, your average is computed only from the sampled subset. The EXTRAPOLATE clause scales results to estimate what the unsampled data would show, which matters when you compare apps with very different traffic volumes.

How to choose

Use these if-then scenarios to pick your query.

If you want the headline number for a report or dashboard tile, run the baseline:

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago

Facet queries return the top 10 results by default. If you have more applications, raise the limit:

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago LIMIT 50

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago LIMIT 50

If you want to see how duration moved across the day, add TIMESERIES and control the bucket size:

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago TIMESERIES 1 hour

SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago TIMESERIES 1 hour

One line per app, one point per hour. This is the version to reach for when someone asks "since when has it been slow?"

If averages look fine but users still complain, check the tail:

SELECT average(duration), percentile(duration, 95) FROM Transaction FACET appName SINCE 1 day ago

SELECT average(duration), percentile(duration, 95) FROM Transaction FACET appName SINCE 1 day ago

A stable average with a spiking 95th percentile means a subset of requests is degrading while most stay fast.

If you need to find which endpoint is the problem, facet on the transaction name as well:

SELECT average(duration) FROM Transaction FACET appName, name SINCE 1 day ago

SELECT average(duration) FROM Transaction FACET appName, name SINCE 1 day ago

If you want milliseconds instead of seconds, do the conversion in the query:

SELECT average(duration) * 1000 AS 'avg duration ms' FROM Transaction FACET appName SINCE 1 day ago

SELECT average(duration) * 1000 AS 'avg duration ms' FROM Transaction FACET appName SINCE 1 day ago

If your agents are sampling, append EXTRAPOLATE:

SELECT average(duration), count(*) FROM Transaction FACET appName SINCE 1 day ago EXTRAPOLATE

SELECT average(duration), count(*) FROM Transaction FACET appName SINCE 1 day ago EXTRAPOLATE

Pairing the average with count(*) is good practice in general: an average computed from three transactions deserves less trust than one computed from three million.

Frequently Asked Questions

Why does my NRQL average differ from the number I see in APM? The APM UI often shows a different time window, applies different filters, or summarizes a different set of transaction types. Check that your SINCE clause matches the UI's time picker, and remember that sampled data without EXTRAPOLATE can skew results on high-traffic apps.

What units is duration in? Seconds. Transaction durations are recorded in seconds, so a value of 0.25 means 250 milliseconds. Multiply by 1000 in the SELECT clause if milliseconds are the convention on your team.

Can I compare today's averages to yesterday's? Yes. Add COMPARE WITH 1 day ago to the baseline query and NRQL returns both periods side by side, which is the fastest way to quantify a regression after a deploy.

Can these queries run outside the query builder? Yes. Save any variant as a dashboard widget for ongoing visibility, or use it as a NRQL alert condition so you get notified when an app's average duration crosses a threshold you define.

Conclusion

The query you need is one clause away from the baseline. Start with SELECT average(duration) FROM Transaction FACET appName SINCE 1 day ago, then decide whether the situation calls for TIMESERIES, percentile(), a second facet, or EXTRAPOLATE. Because every variant uses the same syntax, you can iterate in the query builder and promote the winner to a dashboard or alert without rewriting anything.

If you are evaluating tools rather than queries, the faster path is to get Transaction data flowing first. New Relic's free tier includes 100 GB of monthly data ingestion plus one free full-access user, so you can run every query in this guide against real traffic before committing to anything. Install an agent, open the query builder, and you will have per-app averages within the hour. Sign up at newrelic.com and start with the baseline query above.