# Catch deployments that made your app slower or less reliable > Every hour we compare the 30 minutes before and after each release, and only speak up when a deployment genuinely degraded speed or reliability. - Workflow type: agent - Services: New Relic, Slack, Linear - Categories: Engineering - Published: 2026-08-07 ## What it does - Checks every hour for applications that were deployed recently, so no release goes unmeasured. - Compares the half hour before each deployment against the half hour after it, looking at both error rate and response time. - Only raises an alert when the change is large enough and the service is busy enough to be worth acting on, so a quiet service with a handful of requests never triggers a false alarm. - Posts the before and after numbers side by side in Slack and opens a Linear issue so the regression has a clear owner. ## What you'll need - A New Relic account with the applications you want to watch reporting into it - Deployment markers recorded in New Relic when you release, which is what tells the workflow a new version went out - A Slack workspace and a channel for the alerts to land in - A Linear workspace and a team to file regressions under ## Prompt Every hour, tell me whether anything we just shipped made the product worse. Find the deployments New Relic recorded recently, measure what happened to each application right after the release, and speak up only when a release clearly degraded things. Start with List Applications in New Relic to get every APM application reporting to the account. For each application, call List Deployments and keep the deployment markers recorded in the last 2 hours. Each marker gives you the revision, the description or changelog, the user who recorded it, and its timestamp. Only evaluate a marker once it is at least 30 minutes old and less than 90 minutes old. Anything younger than 30 minutes does not yet have a complete after-window, and anything older was already assessed on an earlier run. This band means every deployment gets judged exactly once, with a full 30 minutes of data on both sides, and never gets reported twice. For each qualifying marker, use Run NerdGraph GraphQL Query to compare the 30 minutes after the deployment against the 30 minutes before it. One NRQL query per window returns all three numbers you need at once: SELECT count(*), percentage(count(*), WHERE error IS true), percentile(duration, 95) FROM Transaction WHERE appName = '' SINCE '' UNTIL '' Wrap it in NerdGraph as actor { account(id: ) { nrql(query: "...") { results } } } and run it twice per deployment: once for the 30 minutes ending at the marker timestamp, once for the 30 minutes starting at it. Remember that NerdGraph reports query errors as a top-level errors array inside an HTTP 200 response, so check for that rather than trusting the status code. Do not raise anything unless the change is both real and measurable. Check throughput first: skip the deployment entirely unless both windows saw at least 100 transactions, because a quiet service with three requests must never start a rollback conversation. Then treat it as a regression only when a metric clears both an absolute and a relative bar. For error rate, that is up by at least 1 percentage point and at least 50 percent relative. For 95th percentile response time, that is up by at least 200ms and at least 25 percent relative. Either metric clearing its pair of bars is enough to report. When a deployment clears those bars, post to the engineering channel with Send a Message in Slack. Name the application, the revision, and who deployed it, then show the before and after numbers side by side so the reader can judge the size of the change without opening New Relic. Include the throughput in both windows so nobody has to wonder whether the sample was big enough to trust. Then use Create Issue in Linear for the same regression so it is owned rather than merely announced. Title it with the application and revision, put the before and after numbers plus the deployment timestamp and the deployer in the description, and reference the Slack message. Set priority by severity, treating an error rate regression as more urgent than a latency one. Stay completely silent when nothing regressed. No Slack message, no Linear issue, no all-clear summary. Most hours will produce no output at all, and that is the correct behaviour: the value of this workflow is that a notification from it always means something genuinely got worse. ## How to customize - Change how sensitive it is by raising or lowering the error rate and response time thresholds that count as a real regression. - Change the minimum traffic required before a comparison counts, so busier or quieter services are judged fairly. - Change which Slack channel gets the alert, which Linear team owns the issue, and how wide the before and after windows are. ## Example output Regression detected after deploy: checkout-api Revision a3f91c2, deployed by maria.lopez at 14:05 UTC Before After Change Error rate 0.4% 3.1% up 2.7 points (+675%) 95th pct response 480ms 1,240ms up 760ms (+158%) Throughput 4,120 3,980 transactions in window Filed as ENG-2841 in Linear. ## FAQ ### Will this ping me every time we deploy? No. It stays completely silent unless a deployment clearly made things worse. Most hours it produces nothing at all, which means a message from it always signals something real. ### What stops it alerting on a service that barely gets any traffic? It requires a minimum amount of traffic in both the before and after windows before it will compare them at all. A service that handled three requests is skipped, because a sample that small cannot tell you anything reliable. ### Does it roll anything back automatically? No. It reports the regression and files it so a person decides what to do. You get the numbers, the version, and who deployed it, then your team chooses whether to roll back or fix forward. ### What happens if we deploy several times in one hour? Each deployment is measured separately and gets its own before and after comparison, so you can see which specific release caused the problem instead of a blended picture. ### Do we need to change how we deploy for this to work? Only if you are not already recording deployments in New Relic. The workflow relies on those release markers to know when a new version went out, what the version was, and who shipped it. Use this prompt in General Input: https://www.generalinput.com/prompts/catch-deployments-that-made-your-app-slower-or-less-reliable