Solve production bugs
fast.

What's 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.

๐Ÿ†

AWARD WINNING

Rails Hackathon 2022 Winner

Voted "Best Solo and Community Favorite."

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.

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

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
White Glove Support
White Glove Support
White Glove Support

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 around_action in your ApplicationController.

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 ).

Calculator

What does an hour of downtime cost you?

/ hour
$ 0.00 / 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.

Join the waitlist

Call Stacking will launch soon. We are slowly onboarding teams.

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