Operations | Monitoring | ITSM | DevOps | Cloud

This month is about shortening the path from detecting a problem to fixing it. You can now create GitHub or Linear issues directly from Scout, Node.js now has complete logs and error monitoring, and Anomaly Detection gets more control over what actually triggers an alert. Here’s what’s new in July.

Last updated: July 2026. Your AI feature works in development. It demos well. Then it hits production and you discover three problems your test suite did not catch: the LLM hallucinates product names that do not exist, the RAG retrieval step adds 4 seconds to every request, and your OpenAI bill is 3x what you budgeted because one prompt template is burning tokens on context that does not help the output. Traditional APM would have caught the latency.

Your AI coding agent can refactor a module, write tests, and open a PR. It can read your codebase, understand your patterns, and suggest changes that follow your conventions. What it cannot do, unless you set it up, is see what is actually happening in production. That is a problem. The agent that writes the code should have access to the errors, traces, and performance data that code generates once it ships. Without production context, your agent is writing fixes based on the code alone.

Your Node.js app is slow and you are not sure where. The response time dashboard shows spikes but not causes. The logs say nothing useful. CPU looks fine. Memory looks fine. Users are complaining anyway. This is the standard Node.js performance debugging experience. The single-threaded event loop, async-everything execution model, and connection pool sharing across all requests make Node.js performance problems different from what you see in Ruby or Python.

Last updated: July 2026. Pricing verified against public vendor pricing pages on July 9, 2026. The monitoring tool market in 2026 is split. On one side, enterprise platforms keep adding features: security scanning, network monitoring, CI/CD integration, cost management. On the other, developer-focused tools are going deeper on what matters during a production incident: how fast you get from alert to the line of code that caused the problem.

Last updated: July 2026 Your Rails app throws a 500. You open Sentry and find the exception. The stack trace points to a controller action, but it does not tell you why the database call failed. You switch to Datadog and search for the request trace. The trace shows a 3-second query, but you do not know what the application was logging at that moment. You open your log aggregator, paste in the request ID, and scroll through output until you find the slow query log line that explains the lock contention.

June was about finishing touches. The fun part. Node.js support, which we previewed in May, is live. Anomaly detection graduated with a rebuilt algorithm, per-monitor controls, and access from the API, CLI, and MCP server. We also kept pulling on the same thread from recent months: Scout data should be reachable from wherever you actually work. The MCP server now covers historical insights, anomaly events, and 30-day metrics. Discord is a notification channel. The CLI has scout anomalies.

The Scout MCP server connects your AI assistant directly to your Scout Monitoring data. Instead of switching between your editor, Scout, and a chat window, your assistant can pull traces, errors, N+1 insights, and endpoint metrics on its own and use that context to suggest or make fixes right in your codebase. This covers how to connect it, what to ask it, how other teams are using it, and what we shipped recently.

We have been getting the same request from teams for a while now: “We use Scout for our Rails app. Can we get the same thing for our Node services?” Today the answer is yes. Scout Monitoring now supports Node.js. If your team runs Express or NestJS in production, you get the same errors-and-traces experience that Ruby, Python, PHP, and Elixir teams have had. Let’s walk through what that means in practice.

You deploy on Friday. Sidekiq starts failing on a job that worked fine in staging. Your error tool shows you a NoMethodError on line 47. But it doesn’t tell you that the job only fails when processing records created after the migration you ran on Thursday. The stack trace is correct and completely useless at the same time. This is the core problem with general-purpose error monitoring on Rails apps. Rails teams deal with N+1 queries that cascade into timeout errors.