Causal is the business and finance planning platform that allows users to build models effortlessly, connect them directly to their data, and share them with interactive dashboards and visuals.
Besides single event investigations, Sentry is also very useful to get a general overview of how our app is performing from dev to QA to production and we use dashboards to make sure that we’re always up to date on how performance is looking across the frontend, the backend and our evaluation service.
Causal deals with complex values and their users rely on them to build equally complex models with real business impact. To that end, user experience needs to be fast and reliable, and for the team to guarantee that, they need detailed visibility into how their app is performing.
Read on to learn how they’ve gained better observability into the performance of their app in production, and made it much easier to track performance over time.
If you’ve ever worked on a frontend app you’ve probably heard ‘our users are saying it’s slow, we don’t really know where that’s happening or if anyone’s reporting it’. We need to be able to see these things before a user reports them.
Andrew’s team knew that, alongside an error monitoring solution, they needed a tool that could automate certain instrumentation processes while leaving room to build custom instrumentation as they added new products and came across unique use cases. For the frontend, any new solution would need to support React and Typescript and on the backend, Express and Go.
On the frontend, the team liked Sentry’s out-of-the-box Redux, Postgres and React instrumentation; and was able to set up a dashboard to monitor all transactions across the frontend to see how they’re performing in real-time.
It’s important for us to know immediately after an update or change whether it’s slowing down our app, before our users report it to us.
On the backend, Sentry equips Causal with the tools to effectively monitor their middleware, and the Express SDK gives the team useful insight into transactions. Additionally, the ability to customize instrumentation helps the team scale as they build new products and come across unique use cases.
Take permissions for example. Andrew’s team has been rethinking their approach to permissions and wrote a whole new system. They needed to get a sense of how it was performing since it’s used in almost every request to the backend and could easily become a bottleneck for subsequent requests.
Another key area they keep an eye on is preprocessed data computation. If this process is slow, everything on the frontend will be slow so they need real-time insights into the proportion of requests taking longer than they should.
Automatic and custom instrumentation for the front-and backend gives the team visibility into the performance of their application. But what if they wanted to run a distributed trace and follow the path of an end-to-end request as it moves from one service to another, investigating multiple operations?
Sorted, here’s how Andrew’s team sees the most important errors or performance bottlenecks in individual services impacting overall system performance:
Besides single event investigations, sentry is also very useful to get a general overview of how our app is performing from dev to QA to production and we use dashboards to make sure that we’re always up to date on how performance is looking across the frontend, the backend and our evaluation service.
Causal’s users rely on their formula editor to calculate different revenue variables, which often involves formulas with complex values. By combining automatic and custom instrumentation around react components, the team is able to see how fast or slow that editor is performing and investigate any bottlenecks. A recent example of this shows how Sentry helped them identify drop in performance with a particular lifecycle method being called, dive deeper into what happened and resolve it:
On the backend, Andrew’s team recently hit a problem where a user’s model was taking longer than expected to evaluate and they couldn’t easily replicate the state of the data locally without considerable effort. With Sentry they were able to identify the slow transaction and see which phase of the dependency graph generation was causing the lag:
Sentry is particularly useful for us to understand problems that are hard to replicate locally.
Initially, Causal used Sentry simply for error monitoring, but since performance is included by default, they started using it and saw how built-in solutions to common problems freed up developer time while customizable instrumentation helped solve performance issues unique to their business.
As we update our own features, we expand our use of Sentry’s custom implementations and get lots of value in both understanding specific performance problems and getting a general sense of how our app is performing.
The Causal team will soon be launching a feature that gives users the ability to evaluate models with 1b+ cells in just seconds, so keep an eye out if you’re a fan. And if you’d like to join their team, they’re hiring across the front-and backend, check out their job listings for more.