AWARD WINNING
Rails Hackathon 2022 Winner
Solve production bugs
fast.
What does an hour of downtime cost you?
(use our calculator to find out)
Decode even the most convoluted Ruby on Rails production incidents with our debugger's powerful visualization, guiding you through the labyrinth of call chains and data flow.
Production issues are hard to debug
Instantly see in production every method call, parameter and return value, for a given request.
You have hundreds, thousands, millions of lines of code to deal with.
For every bug, there's only a few hundred lines that are relevant.
Stop using the Rails console to debug critical issues. Fix your outage in minutes, not hours.
Full, On-demand Tracing
Capture all relevant application method calls for any given endpoint. Turn it off when not needed.
Visibility for argument values for each method call.
When a method call is five layers deep, it can be difficult to manually trace down the value being passed. This value may be coming from the database or being calculated in a parent method several levels up in the call stack, which can require significant effort to trace through the code to identify the source.
Visual nesting of the method calls
You can quickly see which methods are called within each parent method, so you can see the exact execution path the app took for a given endpoint.
Search
Quickly search for any called method or class.
A visual is worth a
1,000 words
Quickly Diagnose a Production Issue
Visually see what methods are being called and under which context.
Paste the call graph image into your incident Slack channel so that everyone can see the execution path.
Debugging via Rails console is a thing of the past.
Incident Triage
Remember, Static Code Analysis & Pull Requests Don't Reveal Everything
When there's a production incident, your first inclination is to look at the code that was changed in the last few days. But old pull requests won't reveal everything.
You need to look at program flow issues - e.g. a method is called via a callback on the application controller, but then there's a redundant call within one of the controller actions.
Or maybe there's an action taken based on a function five levels up the chain - e.g. if the value of a parameter comes from a database value or is calculated far up the call chain, it's really hard to trace that parameter to its originating source and determine if it's a valid value being passed in.
Reconstructing code paths 5 levels deep from the Rails console is a nightmare. When you're under pressure, losing revenue with every down minute, the pressure builds quickly.
Each call graph is an image. Embed those images within your Jira tickets, your Slack channels, PagerDuty comments so that all on-call engineers can quickly visual the call chain.
Incident Onboarding for a Large Codebase
If you have a new engineer, they're on-call, and a production incident occurs, you want to get them up to speed as quickly as possible.
You can't expect any engineer that is tackling a tough production bug to navigate 300,000 lines of code.
The issue with standard debuggers, code navigation (e.g Rubymine), the Rails console or just randomly sprinkling puts statements everywhere, is that you're only getting a sample of the execution. Wherever you place your breakpoint, that's your visibility.
Call Stacking is broader, an unbiased profiler that allows you to envision the entire call stack, without any sort of manual intervention/breakpoints. Call Stacking passively collects all of the important methods, their context, and presents them to your engineer in an easily digestible visual.
The visualization is built automatically for you, without any intervention.
An ecosystem of integrations
Coming Soon
Coming Soon
Coming Soon
Upcoming Plans
Pricing plans for all levels.
Hobby
$?/mo
Team
$?/mo
Enterprise
$?/mo
Usage
Usage
Usage
Usage
Traces per Month
Traces per Month
10
Traces per Month
Unlimited
Traces per Month
Unlimited
Team Members
Team Members
-
Team Members
Unlimited
Team Members
Unlimited
Features
Features
Features
Features
Team Comments
Team Comments
Team Comments
Team Comments
Email Support
Email Support
Email Support
Email Support
Self-hosted version
Self-hosted version
Self-hosted version
Self-hosted version
FAQs
Which teams won't benefit from Call Stacking?
- If your team does not incur revenue loss from downtime attributed to code regressions, Call Stacking isn't needed.
- If your team is senior lead and has a good grasp on your large code base, you probably don't need Call Stacking.
- If your SLAs are loosely enforced and engineers are allowed to respond to incidents on their time, the price of Call Stacking isn't worth it.
- If your application is an internal one and usage is timeboxed between business hours, all bugs are resolved in upcoming sprint cycles, you won't need Call Stacking.
- If code complexity has not been an issue and production incidents have largely been trivial or isolated, Call Stacking isn't needed.
Will the production level tracing impact my performance metrics?
Yes. It's impossible to capture the full context of an app - method calls, parameter values, return values, without adding some additional overhead per request.
How is tracing enabled and disabled?
Tracing is added and then removed on a per request basis using an prepend_around_action in your ApplicationController.
class ApplicationController < ActionController::Base
include Callstacking::Rails::Helpers::InstrumentHelper
prepend_around_action :callstacking_setup
HTTP request times may have to be extended depending on the size of the codebase.
Once the instrumented methods are removed for the request, all subsequent requests for that server will be called with the original implementation.
Only the instrumented requests will incur the overhead of tracing.
What are the requirements needed from my Rails app in order for Call Stacking to be supported?
- Ruby 2+.
- Rails 5+.
- Must have the Rails cache configured
(e.g.Rails.cache.write/read). - Must ActiveJobs configured
(e.g.CleanupJob.perform_later).
