By Nate Rich, Principal Engineer, Foulk Consulting
It’s 2:15 AM on a Saturday. Your phone is blowing up. You stumble to your laptop, eyes blurring, and open New Relic. You see a spike in latency, but the “Why?” is buried under a mountain of data.
At Foulk Consulting, we spent years helping organizations move past “standard” observability. Most teams use New Relic to see that something is wrong. But the real pros use NRQL (New Relic Query Language) to find out exactly what is wrong fast enough to get back to sleep.
Basic SELECT statements are fine for dashboards, but when the pressure is on, you need queries that provide instant context. Here are three “power user” NRQL snippets I keep in my back pocket to save my weekends.
1. The “Is This Actually New?” Query (Baseline Comparison)
The biggest time-waster during an incident is chasing a “spike” that actually happens every week at the same time. You need to know if the current behavior is an anomaly or a pattern.
Instead of looking at a flat line, use COMPARE WITH to overlay today’s performance against last week.
NRQL
SELECT average(duration)
FROM Transaction
WHERE appName = ‘Your-Service-Name’
SINCE 1 hour ago
COMPARE WITH 1 week ago
TIMESERIES
Why it saves your weekend: If the blue line (today) and the yellow line (last week) are hugging each other, it’s likely a scheduled batch job or a known traffic pattern, not a production emergency. You just bought yourself a ticket back to bed.
2. The “Noisy Neighbor” Hunter
When a shared resource (like a database or a microservice) is struggling, it’s rarely because everyone is hitting it hard. Usually, one specific consumer or API endpoint has gone rogue.
This query facets by a specific attribute but filters for the top consumers by volume, allowing you to see who is hogging the “airtime.”
NRQL
SELECT count(*), average(duration), max(duration)
FROM Transaction
WHERE appName = ‘Your-Service-Name’
FACET request.uri
SINCE 30 minutes ago
LIMIT 10
Why it saves your weekend: Instead of guessing which service is causing the slowdown, this query identifies the “Noisy Neighbor.” You might find that a single misconfigured scraper or a specific customer’s API key is responsible for 80% of the load. You can then throttle that specific source rather than panicking over the entire infrastructure.
3. The “Silent Killer” (Success Rate vs. Throughput)
Raw error counts are deceptive. If your traffic drops to zero, your errors will also drop to zero—making your dashboard look “green” even though the site is down.
The percentage function is the most reliable way to monitor the health of your Service Level Objectives (SLOs).
NRQL
SELECT percentage(count(*), WHERE error IS true) AS ‘Error Rate’,
percentage(count(*), WHERE duration <= 0.5) AS ‘Fast Response %’
FROM Transaction
WHERE appName = ‘Your-Service-Name’
SINCE 1 hour ago
TIMESERIES
Why it saves your weekend: This query gives you the ground truth. If your “Error Rate” jumps to 50% while your “Fast Response %” craters, you know you have a functional failure, not just a network flicker. It allows you to ignore the noise and focus on the actual user experience.
Making Observability Work for You
NRQL is more than just a search bar; it’s a diagnostic engine. By moving beyond simple counts and looking at comparisons, distributions, and percentages, you transform New Relic from a “smoke detector” into a “fire suppression system.”
At Foulk Consulting, we specialize in helping teams bridge the gap between “having data” and “having answers.” If your on-call rotations are still feeling like a guessing game, let’s talk. We can help you tune your observability stack so you can spend less time staring at charts and more time enjoying your Saturday.
Need a hand optimizing your New Relic instance? Contact us today.
*** Nate Rich is a Principal Engineer at Foulk Consulting, where he helps enterprises master performance engineering and full-stack observability.
