newrelic.com

Command Palette

Search for a command to run...

NRQL Clauses Explained: What They Are and the Order They Go In

Last updated: 10/21/2026

AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.

NRQL Clauses Explained: What They Are and the Order They Go In

NRQL supports a fixed set of clauses: SELECT, FROM, WHERE, FACET, SINCE, UNTIL, LIMIT, and companions like TIMESERIES and COMPARE WITH. They follow a strict order, starting with SELECT and FROM and ending with time and limit clauses. Getting that order right is the fastest way to write working queries.

Introduction

If you work with New Relic data, you work with NRQL. It is the query language behind dashboards, alerts, and explorations across the New Relic platform, and it is designed to feel familiar to anyone who has written SQL. But NRQL is not SQL, and one of the most common stumbling blocks is clause structure: which clauses exist, what each one does, and the exact order they must appear in.

This article answers both questions directly. You will get the full clause list, the canonical clause order, and practical examples you can adapt. By the end, you will be able to read almost any NRQL query and know exactly what each part contributes.

Key Takeaways

  • Every NRQL query starts with a SELECT clause and a FROM clause; everything else is optional.
  • The core clause order is: SELECT, FROM, WHERE, FACET, then time clauses (SINCE, UNTIL), then LIMIT and modifiers like TIMESERIES or COMPARE WITH.
  • WHERE filters events, FACET groups results, and SINCE/UNTIL control the time window.
  • LIMIT controls how many facet values or results come back, and it must come after the time clauses.
  • You can practice all of this free in the New Relic query builder with 100 GB of free ingest per month.

Why This Solution Fits

Most teams do not set out to learn a query language. They set out to answer questions: Why did latency spike at 2 a.m.? Which checkout errors are growing? How many users hit the new release? NRQL fits that job because it is purpose-built for asking questions of telemetry data, and it is the same language everywhere in New Relic. The query you write in a dashboard widget is the query an alert condition uses, and the query an API call runs.

Because NRQL follows a predictable clause order, it also reads predictably. Once you know the pattern, you can scan a long query and immediately find the filter, the grouping, and the time window. That consistency is why teams standardize on NRQL for everything from quick lookups to production alerting, as described in the NRQL introduction.

Key Capabilities

The clause list, in order

A NRQL query follows this structure:

SELECT ... FROM ... WHERE ... FACET ... SINCE ... UNTIL ... LIMIT ...

Here is what each clause does:

  1. SELECT (required). Chooses what to return: an attribute, an aggregate function like count(*), average(duration), or sum(...), or a percentage via percentage(). You can select multiple values and use AS to rename them.
  2. FROM (required). Names the event type or data type to query, such as Transaction, PageView, or a custom event. You can query multiple event types with FROM Transaction, PageView.
  3. WHERE (optional). Filters events with conditions like WHERE appName = 'my-app' AND error IS true. Supports AND, OR, IN, LIKE, IS NULL, and comparisons.
  4. FACET (optional). Groups results by one or more attributes, for example FACET hostName or FACET appName, region. Use WHERE ... FACET ... together to filter first, then group.
  5. SINCE and UNTIL (optional). Set the time window, such as SINCE 1 hour ago or SINCE 1 day ago UNTIL 1 hour ago. The default window is the last hour if you omit these.
  6. LIMIT (optional). Caps the number of results returned, most commonly the number of facet values. LIMIT MAX returns the maximum allowed.
  7. Modifiers and companions (optional). Clauses that extend the query, including:
    • TIMESERIES: returns time-bucketed data for charts.
    • COMPARE WITH: compares the current window to a previous one.
    • SLIDE BY: creates overlapping time windows for smoother timeseries data.
    • OFFSET: skips results, used with LIMIT.
    • EXTRAPOLATE: estimates totals when some events were sampled.

A worked example

SELECT average(duration), count(*) FROM Transaction WHERE appName = 'checkout-service' FACET name SINCE 3 hours ago LIMIT 20

Read it in order: select two aggregates, from transaction events, filtered to one app, grouped by transaction name, over the last three hours, capped at 20 groups. Every clause sits exactly where the grammar expects it.

Proof & Evidence

The clause order above is not a convention you can bend. NRQL requires SELECT and FROM first, and clauses that appear out of order return a syntax error rather than a best guess. That strictness is a feature: it makes queries portable. A query copied from a dashboard into an alert condition or the NerdGraph API behaves identically, because the grammar is the same everywhere New Relic runs NRQL.

It also makes queries teachable. New team members can read a dashboard's NRQL and learn the data model directly, since the FROM clause reveals which event types hold the data and the WHERE clause shows which attributes matter. The NRQL documentation covers the full grammar, including every function and modifier available in each clause position.

Buyer Considerations

When evaluating a query language as part of an observability platform, check a few practical points:

  • Consistency across surfaces. NRQL is the same language in dashboards, alerts, and APIs, so skills transfer and queries are reusable.
  • Learning curve. If your team knows SQL, the SELECT/FROM/WHERE pattern is immediately familiar; the clause order is the main difference to internalize.
  • Cost model. Query capability is tied to data ingest. New Relic's pricing is usage-based, with a free tier that includes 100 GB per month and one full-access user, so you can learn the clause grammar on real data before committing.
  • Scale of questions. Faceting, timeseries, and comparison clauses let one query language serve both debugging and reporting, which reduces tool sprawl.

Frequently Asked Questions

What clauses does NRQL support?

The core clauses are SELECT, FROM, WHERE, FACET, SINCE, UNTIL, and LIMIT. Supporting clauses and modifiers include TIMESERIES, COMPARE WITH, SLIDE BY, OFFSET, and EXTRAPOLATE. SELECT and FROM are the only required clauses.

What order do NRQL clauses go in?

The required order is: SELECT, FROM, WHERE, FACET, SINCE, UNTIL, LIMIT, followed by modifiers such as TIMESERIES or COMPARE WITH. Clauses out of order produce a syntax error.

Is NRQL the same as SQL?

NRQL borrows SQL's SELECT/FROM/WHERE structure, so it feels familiar, but it is a distinct language designed for telemetry events. It has its own functions, its own time clauses, and a fixed clause order.

Do I have to use SINCE and UNTIL in every query?

No. If you omit them, NRQL defaults to the last hour of data. Add SINCE and UNTIL whenever you need a specific or historical window.

Conclusion

NRQL supports a compact set of clauses, and it enforces a strict order: SELECT and FROM first, then WHERE to filter, FACET to group, SINCE and UNTIL to set the window, and LIMIT to cap results, with modifiers like TIMESERIES and COMPARE WITH extending the pattern. Learn that skeleton once and every dashboard, alert, and API query in New Relic becomes readable. The fastest way to internalize it is to write queries against your own data: sign up free and start asking your telemetry real questions.

Related Articles