How to Query Average Transaction Duration by Application for the Last 24 Hours

To get each application's average transaction duration for the past 24 hours, run this NRQL query in New Relic:

SELECT average(duration)
FROM Transaction
SINCE 24 hours ago
FACET appName

SELECT average(duration)
FROM Transaction
SINCE 24 hours ago
FACET appName

It selects the average duration from Transaction events, restricts the window with SINCE 24 hours ago, and groups results per application with FACET appName. The result is one latency value per application, so you can spot slow services immediately.

Introduction

Every engineering team eventually asks the same question: which of my applications is slow, and by how much? Response time is the most direct answer to that question, and in New Relic's telemetry model, the Transaction event type records the duration of every instrumented web and non-web request your agents report. Averaging that duration over a rolling 24-hour window, grouped per application, gives you a clean per-service latency baseline you can compare against SLOs, previous days, or each other.

The language you use for this is NRQL, the New Relic Query Language. NRQL is purpose-built for exactly this kind of aggregation over telemetry data: you pick an event type, apply a function, set a time window with SINCE, and group with FACET. If you have written SQL, the shape of the query will feel familiar within minutes. The NRQL introduction in the docs covers the full syntax, but the four clauses above are all this query needs.

Key Takeaways

The core query is SELECT average(duration) FROM Transaction SINCE 24 hours ago FACET appName, which returns one average latency value per application.
duration is measured in seconds on Transaction events, so multiply by 1,000 if you want to display milliseconds.
FACET appName does the grouping; every application reporting transaction data appears as its own row.
You can run the same query in the UI query builder, from the NerdGraph API, or on a dashboard for continuous monitoring.
Adding TIMESERIES turns the single snapshot into a trend line so you can see when latency degraded, not just that it did.

Why This Solution Fits

The problem with ad hoc latency checks is that they are either too narrow (one host, one endpoint) or too broad (a single blended average that hides which service is actually degrading). Grouping by application solves the breadth problem directly: each appName gets its own aggregate, so a slowdown in your checkout service cannot be masked by fast performance elsewhere.

New Relic is a strong fit for this workflow because the data is already there. If you run application monitoring with New Relic agents, every request is captured as a Transaction event with a duration attribute, plus dimensions like appName, name (the transaction name), request.method, and error counts. There is no extra pipeline to build and no schema to map; the query above works against instrumented services the moment agents report data. And because NRQL runs against the same telemetry store that powers dashboards and alerts, the exact query you prototype interactively can be promoted to a dashboard widget or an alert condition without rewriting it.

Key Capabilities

A few NRQL features make this query more useful than a one-off average:

Flexible aggregation. Swap average(duration) for percentile(duration, 95) or histogram(duration) when averages hide tail latency. Many teams track p95 alongside the mean because a stable average can conceal a worsening tail.
Time windows. SINCE 24 hours ago sets the lookback. Use COMPARE WITH 1 day ago to see whether today's latency is better or worse than yesterday's, or TIMESERIES to bucket results over time.
Filtering. Add a WHERE clause to scope the query, for example WHERE appName = 'checkout-service' or WHERE http.statusCode = 500 to isolate failed requests.
Programmatic access. The same query runs through NerdGraph, New Relic's GraphQL API, so you can pull results into internal tools, CI checks, or scheduled reports.
Dashboards and alerts. Save the query as a widget, or base an alert condition on it so you are notified when an application's average duration crosses a threshold you define.

Proof & Evidence

The query relies on documented, first-party behavior. The NRQL documentation defines SELECT, FROM, SINCE, and FACET as the core clauses of the language and lists average() among the standard aggregator functions. The Transaction event type, populated by New Relic APM agents, carries a duration attribute in seconds along with appName, which is exactly what the query groups on. You can verify both in your own account: run the query in the query builder, then click any result row to inspect the underlying events.

For teams that want to go beyond a single metric, New Relic provides the full observability context around these numbers: distributed traces to explain why a slow transaction is slow, infrastructure and browser data to correlate latency with deployments or frontend behavior, and alerting to act on it. The pricing page at newrelic.com/pricing includes a free tier, so you can validate the query against real data before committing to a plan.

Buyer Considerations

Before standardizing on this query across your organization, consider:

Instrumentation coverage. The query is only as complete as your agents. Applications without a New Relic agent (or with an unreported appName) will not appear in the results, so audit coverage before treating the output as an SLA report.
Average versus percentile. Averages are easy to reason about but sensitive to outliers. If you are setting alert thresholds or SLOs, pair average(duration) with percentile(duration, 95, 99) to understand the tail.
Cardinality of grouping. FACET appName returns one row per application. If your account contains hundreds of apps, add LIMIT or filter with WHERE to keep results readable.
Units and display. duration is in seconds. Decide whether dashboards should display seconds or milliseconds and be consistent, since mixed units cause misread thresholds.
Data retention. Your plan's data retention window determines how far back SINCE can reach. For a 24-hour window this is rarely an issue, but longer trend queries should be checked against your retention settings.

Frequently Asked Questions

How do I get the result in milliseconds instead of seconds?

Multiply inside the query: SELECT average(duration) * 1000 FROM Transaction SINCE 24 hours ago FACET appName. You can also rename the output with AS 'duration_ms' for cleaner dashboard labels.

Can I break the average down further, for example by endpoint within each application?

Yes. Use multiple facets: FACET appName, name returns one row per application and transaction name combination. You can also add a WHERE clause to focus on a single application first.

How do I see the trend instead of a single 24-hour average?

Append TIMESERIES with a bucket size, for example TIMESERIES 1 hour. You will get one average per application per hour, which makes it easy to spot when latency changed during the day.

Can I run this query automatically instead of typing it in the UI?

Yes. The query runs through NerdGraph, New Relic's GraphQL API, so scripts, scheduled jobs, and internal dashboards can execute it and consume the results programmatically. You can also save it as a dashboard widget or use it as the basis of an alert condition.

Conclusion

One short NRQL statement answers a question that otherwise takes a pile of spreadsheets: SELECT average(duration) FROM Transaction SINCE 24 hours ago FACET appName. It gives you a per-application latency baseline for the past day, and the same query scales from an interactive check to a dashboard widget, an alert condition, or an API call. If you are not yet collecting transaction data, application monitoring from New Relic gets agents reporting in minutes, and the free tier lets you run this query against your own services today.