Operations | Monitoring | ITSM | DevOps | Cloud

Resque 3.2.0 shipped on October 16 with a single change, listed under Security: resque-web now rejects state-changing requests that come from another site. Until this release, resque-web had no cross-site request forgery (CSRF) protection at all. A page on any other site could submit a form to your dashboard and clear your failed jobs or delete a queue, as long as the browser it ran in could reach resque-web and was logged in to it. The fix is small and most teams can upgrade without touching anything.

October was about making Scout’s data easier for AI tools to use and easier for your team to trust. Scout is now in Claude’s connector directory, the MCP server got leaner and more careful about what it returns, and Scout Trails opened its beta. Anomaly Detection also became easier to read and better at catching short spikes. Here’s what shipped in October.

A customer messages support: checkout feels slow today. You open Scout, find the endpoint, open a trace, spot the query, copy it into Claude, and ask what’s wrong with it. Each step is quick, but together they add up to a lot of tab switching to answer one question. Scout Monitoring is now available in Claude’s connector directory. Connect it once and Claude can look at your production data directly.

FastAPI released 0.146.0, 0.147.0, and 0.148.0 between Sunday afternoon and Monday morning (UTC), and each one is labeled a breaking change. None of them will crash your app on startup. They change what values your endpoints receive, which is the kind of change that passes CI and then shows up as odd data a week later. At Scout Monitoring, we monitor a lot of FastAPI apps, and a loosely pinned fastapi dependency is the most common way these releases will arrive.

session start tool call tool call cost outcome AI coding agents have quietly become part of most engineering teams. They open files, run commands, call tools, and push changes, often for hours at a time. Yet when you want to know what an agent actually did, the answer usually lives in one developer’s terminal history, and it disappears when that session closes.

If your Grape API calls error! inside an Active Record transaction, the client gets an error response and the database keeps the writes. No exception, no warning, no rollback. The request looks failed from the outside and succeeded on the inside. A fix merged into Grape on October 3 and is queued for Grape 4.1.0. It’s not released yet, so every current Grape version still behaves this way. Here’s why it happens, how to check whether you’re affected, and what changes when 4.1 ships.

The standard fix for an N+1 query in SQLAlchemy is to eager load the relationship with selectinload(). On SQLAlchemy 2.1.0 and 2.1.1, that fix can change your results. A regression in those two releases makes selectinload() ignore part of the join condition on some many-to-many relationships. The query gets faster, and it also returns related rows that the relationship was defined to exclude. It’s fixed in 2.1.2, released October 2.

FastAPI 0.142.0 ships with OpenTelemetry built in. Install fastapi, set one environment variable, and every request produces a trace, metrics, and error logs. No middleware, no instrumentation package, no code. That’s a big change for a framework most Python teams instrument by hand. It’s also easy to misread. The defaults record more than some teams expect in one place, and less than others assume in another. Here’s what you actually get.

Your AI coding agent can read your code, run your tests, and open a pull request. Until recently it could not see what that code does in production. MCP servers from monitoring vendors close that gap. Connect one, and Claude Code, Cursor, or Copilot can pull the error, the trace, and the slow query behind a bug report without you copying anything out of a dashboard. Most major monitoring vendors now offer an official MCP server. But they aren’t interchangeable. Some only expose errors.

A bot requests /wp-login.php on your Rails app. Rails can’t route it, raises ActionController::RoutingError, and returns a 404. That should cost almost nothing. On a Rails 8.1 app with a few thousand compiled templates, it can cost 13 MB of allocations and 27 ms of CPU. A detailed report on rails/rails#58887 traces the cost to one method, ActionDispatch::ExceptionWrapper#build_backtrace.