# Weekly New Relic application performance review in Slack

> Every Monday at 8am, get a plain-English review of which applications actually got better or worse last week, posted to Slack and logged to Google Sheets.

- Workflow type: agent
- Services: New Relic, Slack, Google Sheets
- Categories: Engineering
- Published: 2026-08-07

## What it does

- Checks every application reporting into your New Relic account and pulls last week's response times, error rates, traffic levels, and user satisfaction scores, plus the same figures for the week before.
- Writes a short narrative that names only the applications that genuinely moved, and says in plain words whether each one got better or worse.
- Ranks the write-up by how many real users were affected, so a tiny service with a dramatic percentage swing does not crowd out a busy one that slipped a little.
- Posts the summary to your team channel and adds a row per application to a running spreadsheet, so you build a performance history that no dashboard keeps for you.

## What you'll need

- A New Relic login for the account your applications report into
- A Slack workspace and a channel where the weekly review should land
- A Google account and a spreadsheet to use as the running tracker
- Around two weeks of performance history in New Relic, so the first report has a prior week to compare against

## Prompt

Every Monday at 8am, write me a plain-English review of how our applications actually performed last week. Run this on a cron schedule.

Start with New Relic List Applications to get every APM application reporting to the account. Keep each application's name and id so later steps can line the numbers up with the right service.

Then use New Relic Run NerdGraph GraphQL Query to run NRQL for two windows: last week (SINCE 1 week ago UNTIL now) and the week before it (SINCE 2 weeks ago UNTIL 1 week ago). For each application and each window pull four figures: the Apdex score, the error rate, the throughput, and the 95th percentile response time. A query shaped like SELECT apdex(duration, t: 0.5), percentage(count(*), WHERE error IS true), count(*), percentile(duration, 95) FROM Transaction FACET appName covers all four at once, and faceting by appName lets you cover many applications per query instead of one query per application, which keeps the run inside NerdGraph's per-query complexity limits. Note that NerdGraph reports query and validation failures as a top-level errors array inside an HTTP 200 response, so check for that rather than trusting the status code.

Ignore applications with negligible traffic so low volume services do not dominate the regression list. As a default, skip any application with fewer than 1,000 transactions in the week being reported, and skip any application that did not report data in both weeks, since there is nothing to compare.

Name only the applications that moved materially week over week, and say plainly whether each one got better or worse. As defaults for material: Apdex moved by at least 0.05, error rate moved by at least half a percentage point or at least 25 percent in relative terms, or the 95th percentile response time moved by at least 20 percent. Everything inside those bands is normal variation and should not be named.

Order the narrative by how many real users were affected, not by raw percentage change. Estimate impact from the volume sitting behind the move: the change in error rate multiplied by the week's transaction count gives roughly the number of additional failed requests, and response time regressions should be weighted by throughput the same way. A 40 percent error rate jump on a service handling 200 requests a week ranks well below a 3 percent jump on one handling two million.

Post the narrative to Slack with Send a Message to the channel I name. Keep it readable in a channel: a one line headline with how many applications were checked and how many moved, then a short paragraph per application that moved, worst real impact first. Use Slack mrkdwn formatting, so *bold* rather than **bold**. If nothing moved materially, still post a short all steady note naming the number of applications checked, so I know the review ran.

Finally, append to the trend tracker with Google Sheets Append Values. Append one row per application for the week that just ended, with the week start date, application name, Apdex score, error rate, throughput, and 95th percentile response time. Do not append rows for the prior week, it is only there for comparison and re-appending it would duplicate a week of history on every run. Log every application that reported data, including the low traffic ones left out of the narrative, so the accumulated history stays complete. Write the values as user entered so dates and numbers land as real dates and numbers rather than text.

## How to customize

- Change the timing, for example Friday afternoon instead of Monday morning, or every other week
- Raise or lower the traffic floor that decides which applications are too quiet to report on, and how big a swing has to be before it counts as material
- Send it to a different channel, or post it as a workspace bot instead of as yourself
- Add extra figures to the spreadsheet tracker, such as slowest transaction or host count

## Example output

*Weekly application performance review, week of 28 Jul*

14 applications checked, 9 above the traffic floor, 3 moved materially.

*checkout-api* got worse. Error rate rose from 0.4% to 1.9% on 2.1M requests, which is roughly 31,000 extra failed requests versus the week before. This is the biggest real user impact of the week.

*web-storefront* got worse. 95th percentile response time went from 820ms to 1,240ms on 4.4M requests, with the user satisfaction score slipping from 0.94 to 0.88.

*search-service* got better. Error rate fell from 2.2% to 0.6% on 380k requests, clearing up around 6,000 failed requests a week.

Everything else held steady inside normal variation. Full figures appended to the tracker.

## FAQ

### Will this flag every small fluctuation in performance?

No, and that is the point. It only names an application when the change clears a materiality threshold, and it ignores applications with very little traffic. A normal week where nothing really moved produces a short all steady note instead of a wall of noise.

### What if none of my applications changed much last week?

You still get a message. It posts a brief note confirming how many applications were checked and that nothing moved materially, so you know the review actually ran rather than silently failing.

### Does this work on a free New Relic plan?

It works with any account that has applications reporting performance data. The one thing to check is how long your plan keeps that data, because the report compares last week against the week before. If your retention window is shorter than two weeks, shorten the comparison to the last few days versus the previous few days.

### What counts as a material change?

By default a meaningful shift in user satisfaction score, a jump or drop in error rate of around half a percentage point or a quarter in relative terms, or a change of roughly a fifth in the slowest typical response time. All of those thresholds are yours to tune once you see a couple of reports.

### Why order by users affected instead of by percentage change?

Because percentage change flatters low traffic services. An error rate that triples on a service handling a couple of hundred requests a week matters far less than a small slip on one handling millions. Ranking by the number of people who actually felt the change puts the real problems at the top.

Use this prompt in General Input: https://www.generalinput.com/prompts/weekly-new-relic-application-performance-review-in-slack