Articles by Sara Hyman

You approved an APM tool at a modest monthly rate. A year later, the renewal invoice bears little resemblance to what you signed, and nobody remembers deciding to spend that much more.

APM is worth having when it’s used well: it resolves incidents faster by showing you where in the stack a problem started, it gives you warning before a threshold alert turns into an outage, and it gives you a defensible answer when a client or stakeholder asks whether you hit your SLA (often measured through percentile response times opens a new window like p95 and p99). None of that is in question here. What tends to go unexamined is whether the bill still matches what you’re getting for it.

In this article, we’ll walk through where APM spend typically concentrates, the warning signs that a bill has drifted from usage-driven growth into unmanaged creep, and a concrete checklist for getting ahead of it before your next renewal.

Many Rails teams that we have worked with have a version of the same story: a test suite that grew organically, was never quite prioritized, and now sits somewhere between “unreliable” and “actively avoided.” Maybe tests are slow. Maybe they’re flaky. Maybe coverage gaps makes deployments feel like a roll of the dice. Or a manual battle against a behemoth of a beast. It is likely you have heard engineers gripe about the test’s reliability and may be worried that they are sinking time in the application.

Improving your test suite is one of the highest leverage investments a development team can make even though it’s often deprioritized. While the benefits are not always obvious to those that approve budgets and sign contracts, issues related to the test suite can become a sifon of time, budget and team energy. Optimizing your test suite requires critical knowledge of the application and its business functions that require management and direction from experienced engineers, especially if leveraging AI models.