Operations | Monitoring | ITSM | DevOps | Cloud

You’ve watched Claude Code compact a conversation. The context bar fills, it pauses, a summary appears, and it carries on like nothing happened. You probably assumed a housekeeping script trimmed the transcript in the background. It didn’t. The model compacted itself. When the window fills, Claude Code sends a long, specific prompt telling the model how to summarize its own conversation. Then it does, same model, same turn. The thing managing your context window is just another instruction.

While logging into one’s LinkedIn will spew out endless talk of AI possibilities from “thought leaders” and the semi-disconnected alike, another pocket of the world spent the last few weeks watching the Shai-Hulud worm chew through npm. A self-propagating credential stealer that hit 400-plus packages and, delightfully, planted Claude Code and VS Code hooks so just opening the repo could run its payload.

NestJS 12 dropped last week with ESM packages, Standard Schema validation, a rebuilt CLI, and a brand-new observability SDK. That last one is the most interesting part for anyone running NestJS in production with an APM tool. At Scout Monitoring, we instrument NestJS applications through our Node.js agent. A framework shipping its own observability layer changes the conversation for every APM vendor in the ecosystem, including us. Here is what you need to know.

If you run Starlette or FastAPI in production with an APM tool, you should keep an eye on PR. It adds native OpenTelemetry HTTP server spans directly into the framework. No external instrumentor, no monkeypatching. Just spans emitted from the router itself. At Scout Monitoring, we instrument Starlette and FastAPI through our Python agent. A change like this touches how every APM tool in the Python ecosystem works with these frameworks, ours included.

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.