Call Stacking

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.

Sign up now ->

Not interested in Call Stacking at the moment?

Let's keep in touch..

    We won't send you spam. Unsubscribe at any time.

    🏆

    AWARD WINNING

    Rails Hackathon 2022 Winner

    Voted "Best Solo and Community Favorite."
    Sign up now->

    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.

    Icon 01
    Full, On-demand Tracing
    Capture all relevant application method calls for any given endpoint. Turn it off when not needed.
    Icon 04
    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.
    Icon 02
    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.
    Icon 03
    Search
    Quickly search for any called method or class.
    Sign up now->

    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.

    Feature
    Sign up now->

    An ecosystem of integrations

    Ruby on Rails
    PHP Coming Soon
    NodeJS Coming Soon
    Java Coming Soon

    Upcoming Plans

    Hobby
    Team
    Enterprise
    Usage
    Usage
    Usage
    Traces per Month
    10
    Traces per Month
    Unlimited
    Traces per Month
    Unlimited
    Team Members
    -
    Team Members
    Unlimited
    Team Members
    Unlimited
    Features
    Features
    Features
    Team Comments
    Team Comments
    Team Comments
    Email Support
    Email Support
    Email Support
    Self-hosted version
    Self-hosted version
    Self-hosted version
    Sign up ->
    Sign up ->
    Sign up ->

    FAQs

    Which teams won't benefit from Call Stacking?

    1. If your team does not incur revenue loss from downtime attributed to code regressions, Call Stacking isn't needed.
    2. If your team is senior lead and has a good grasp on your large code base, you probably don't need Call Stacking.
    3. 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.
    4. 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.
    5. 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 ).

    What does an hour of downtime cost you?

    / hour
    $ 87,991.23 / year.

    The Impact of an Outage is Amplified by the Time to Resolution

    • Trust with existing users is lost.
    • Growth of new users is compromised.
    • Employees that are busy diagnosing bugs are not working on new features. They are not generating revenue.

    Revenue cannot grow if your product is unreliable.

    When instability arises,
    you need to get to root cause fast.

    Sign up now->
    © 2025 Blue Sage Data Systems, Inc
    About Privacy Policy Terms of Service Attributions
    Ruby on Rails, Debugging in Production Ruby on Rails, Existing Debugging Tools