Operations | Monitoring | ITSM | DevOps | Cloud

The error monitoring scene has changed a ton over the past few years. We've gone from basic exception tracking to fully integrated platforms that correlate errors with performance metrics and logs. We’ve even got AI-powered debugging! But in the midst of the AI explosion, some things remain unchanged and most teams are still drowning in data with little actionability.

With modern tooling and agentic coding assistants, straightforward bugs are almost a relief. If a test can catch it, or a user can reproduce it, chances are you can squash it quickly. The harder category — and the one worth writing about — are the bugs where everything looks correct. Your code runs, no exceptions are thrown, your debug statements confirm the right functions fire at the right times, and yet nothing works.

A repository for this article can be found here.‍ When most developers think about request tracing, they picture instrumentation hooks inside familiar libraries. This allows us to track familiar metrics we see in application performance monitoring (APM) tools such as the duration of an HTTP call or how long a database query takes. But what if you could go deeper and instrument your own Ruby code automatically, without sprinkling timing calls everywhere?