I did not build DeadBro because the world needed another monitoring dashboard. I built it because, after years of working on Rails applications, I was still being told that an endpoint was slow when what I needed to know was which line of which partial made it slow.
That difference sounds small. In production, it is the difference between receiving an alert and having an answer.
Most application monitoring products are designed to support every language, framework and deployment model. That breadth is useful, but it comes with a trade-off: the product can see a request, a database call and an exception, yet it often cannot explain the Rails-specific chain connecting them.
I wanted monitoring that understood the application the way a Rails developer does. So in August 2024, I started building DeadBro, a Rails application performance monitoring platform focused on turning production symptoms into code I can act on.
01 An alert is not an explanation
The usual performance investigation starts with a route and a duration: this request took 1.8 seconds. That is enough to tell me that users had a bad time. It is not enough to tell me what to change.
A slow Rails request may spend its time in a controller, an Active Record query, a serializer, a helper, a view or a partial rendered hundreds of times. The total duration hides those decisions. A generic trace can still leave me moving between dashboards, logs and source code, reconstructing the request by hand.
I wanted the path to be explicit: request to controller, controller to query, query to view, and view to the exact partial responsible. If an N+1 query begins on a particular source line, the useful result is not merely “N+1 detected.” The useful result is the file and line number I can open.
Monitoring should shorten the distance between “something is wrong” and the commit that fixes it.
That principle became the product test for DeadBro. If a piece of telemetry does not help me understand or fix the application, it does not earn space in the interface.
02 Rails-only is a feature
The obvious business advice is to support more frameworks. A larger market looks better on a spreadsheet. But supporting everything would push DeadBro toward the same compromise that made me want to build it in the first place.
DeadBro is Rails-only by design. That lets it understand the framework rather than treating it as another Rack process. It can follow request rendering into views and partials, connect repeated database work to the code that triggered it, track exceptions with application context, and monitor background jobs alongside web requests.
The product brings together the things I repeatedly need while operating a Rails application:
- request traces that include controller, database and view work
- N+1 query detection with source locations
- error tracking with enough context to reproduce the failure
- background-job monitoring
- uptime monitoring in the same place as application performance
None of those capabilities is unusual on its own. The point is that they share one Rails-native model of the application. I do not want five tools giving me five versions of the same incident.
03 Cost is part of the architecture
I have seen monitoring bills grow into something teams actively avoid looking at. Once that happens, the tool starts working against its purpose. Sampling becomes aggressive, retention shrinks, or monitoring is disabled on the applications that need it most.
I did not want DeadBro priced around how a customer happens to deploy. A Rails application should not become more expensive to observe merely because it runs across more hosts or containers. DeadBro is priced by tracked request instead.
The infrastructure follows the same philosophy. DeadBro runs on EU bare metal. That gives me control over the cost base and where the data lives, without building a pricing model around layers of resold infrastructure.
Affordable monitoring is not a discount feature. A monitoring product that becomes too expensive to leave enabled is not reliable infrastructure.
04 The first customer is DeadBro
I am the solo founder, which means product decisions, instrumentation, ingestion, storage, deployment, support and the invoice eventually arrive at the same desk.
It also means I can dogfood the complete system. DeadBro monitors DeadBro every day. Its own requests, errors, jobs and uptime pass through the same product customers use. When a trace is confusing or an alert lacks context, I experience that failure directly.
Dogfooding does not guarantee a good product, but it removes a convenient category of excuses. I cannot call a workflow good enough when I am frustrated by it during an incident.
05 Building the tool I want to keep using
The original goal has stayed remarkably stable: make Rails performance visible, explain what the application is doing, and keep the product affordable enough to leave on.
There will always be more metrics I could collect and more markets I could chase. The harder founder decision is deciding what not to add. DeadBro should remain opinionated, because opinion is what turns framework events into a useful explanation.
I am building it for the developer who already knows an endpoint is slow and wants to know why; for the small team that needs errors, jobs and uptime without assembling an observability department; and for the Rails application that deserves tooling designed around how it actually works.
If that sounds like your application, take a look at DeadBro’s Rails APM and error monitoring. I use it on the product itself every day, and I am still building it around the same question: does this help me fix the code?