Operations | Monitoring | ITSM | DevOps | Cloud

Last updated: May 2026 If your team is 2 to 20 developers and you do not have dedicated DevOps, SRE, or platform engineering, most APM tools were not built for you. They were built for the team that has you: a team with specialists who can tune dashboards, configure alerting pipelines, manage data retention policies, and explain the monitoring system to everyone else. You do not have that team. You have developers who also handle deploys, on-call, and debugging production issues between writing features.

AI coding assistants have made it possible for a single developer to build and ship a production application in a weekend. Claude Code, Cursor, GitHub Copilot, and similar tools can scaffold a Rails app, write the models, generate the views, wire up the API, and push to production before Monday. This is genuinely exciting. It is also genuinely dangerous if you do not have monitoring in place before you ship.

Last updated: May 2026 Elixir applications have performance characteristics that are genuinely different from Ruby or Python. The BEAM virtual machine handles concurrency through lightweight processes, supervision trees restart failed processes automatically, and Phoenix channels can hold tens of thousands of persistent connections on a single node. These are strengths, but they also mean that the performance problems you encounter are different from what most APM tools were built to detect.

N+1 queries are the most common performance problem in Rails applications. ActiveRecord’s lazy loading means every belongs_to, has_many, and has_one association is a potential N+1 waiting to happen. The good news is that Rails gives you multiple ways to fix them, and tools like Scout can find them automatically. This guide covers everything a Rails developer needs to know about N+1 queries: what they are, how to fix them, how to prevent them in CI, and how to detect them in production.

A modern web application is not a single thing. A single user request may touch a web server, a database, a cache layer, and several third-party APIs before a response comes back. And as AI tools generate more and more application traffic (API calls, background jobs, automated workflows), the volume and unpredictability of that traffic is growing. When something goes wrong, it could be any of it. When something is slow, it could be all of it at once.

The tension between shipping speed and application performance has not changed much since this post was first published in 2020. What has changed is how quickly a team can detect, diagnose, and fix a problem. That difference is significant enough to warrant a revisit. The scenario from the original still plays out every week. Sales brings a priority feature that might degrade performance for some customers. The developer ships it and watches what happens.

Today, we are taking a break from your regularly scheduled technical programming to talk about support. Here at Scout, we consider support one of our differentiators, and even as we adopt AI as a human multiplier behind the scenes, we are committed to keeping it real on the human-interaction side. It will be a long time, if ever, that you reach out to us and get a response from an AI agent. Would it be cheaper? Sure, but it isn’t up to our standards, and we won’t compromise on that.

Most teams triage errors the same way. Check the error tracker in the morning, skim the stack traces, pick the ones that look urgent, start investigating. The rest pile up. By the time anyone gets to the long tail of production errors, the context is stale and the motivation is gone. What if that first pass happened automatically? We’ve been experimenting with a workflow that connects Scout’s error data to AI assistants through our MCP server.

If you’ve spent any time in developer tooling lately, you’ve probably noticed a pattern: every product is rushing to add a chatbot, an AI summary, or some kind of “magic” button. We get it — it’s tempting. But at Scout, we’ve been deliberately taking a different approach. Instead of building AI into our product first, we’ve focused on making Scout’s data accessible to the AI tools you’re already using.

Elixir’s “let it crash” philosophy is one of the best ideas in modern software design. Supervisors restart failed processes, the system self-heals, and life goes on. It’s like having a really good immune system. The problem is that a really good immune system can also hide chronic conditions. A GenServer crashing and restarting is working as designed.