Share on Twitter
Share on Facebook
Share on HackerNews
Share on LinkedIn

Dogfooding Chronicles: Tracing the path from “It’s Slow” to “What’s Slow”

Dogfooding is the practice of sampling your own product before the public does. For dog food executives, chowing down on their own kibble is a literal gut-check. For Sentry, we’ve been using Performance in advance of its upcoming release as a way to think through our own issues, all so we can give you better visibility into yours.

Context is critical for software teams. It bridges the gap between a problem to solve and the right person to solve it. And confusion fills the void left by context: “That’s not my job” could be pointing fingers — or it could be pointing you in the right direction. So when a product demo went off-schedule, it was up to us to use Sentry to not only find out what was wrong — but to find the right team to fix it.

The Problem

Neil (solution engineer) and Rahul (product marketer) were demoing Sentry’s new Releases capabilities. And in the longstanding tradition that all demos must troll their presenters, the Releases page was taking more than five seconds to load.

The Process

At first, Rahul thought Neil’s glacial internet connection was at fault. To confirm this, Rahul messaged Dave, our head of product. Using Discover, Dave queried new transaction events to see that Neil’s internet connection wasn’t the problem at all.

A one-line update to your Python or JavaScript SDK gets you access to application performance data.


Dave figured that if it wasn’t Neil’s connection causing the slow load, then it had to be the Releases team. But before Dave began smiting the Releases team with passive-aggressive Slack messages, he decided to use Sentry’s new tracing features to get some more context into why the page was taking five seconds to load.

With Sentry’s Performance, you can trace any transaction to a single API/request call. Here, the team discovered it was an improperly instrumented API — a task for the Enterprise team, not Releases. Crisis averted.


Using Performance, the team was able to think through the noise — both technical (instrumentation) and human (blame). And with full visibility into what caused the error, the team now had full confidence to resolve it.

Blame Game Over

For developers, there’s a big difference between knowing something’s wrong and knowing what’s wrong. For Rahul, Neil, and Dave, it was the difference between a round of celebratory beers and a round of apology emails. That’s the value of context, and that’s what Performance proved here. It’s why we built Performance — by delivering a better application monitoring experience for you, you’re able to deliver a better experience for your customers.

Sentry’s Performance features are currently in beta. For more details about access to these features, feel free to reach out at

Your code is broken. Let's Fix it.
Get Started

More from the Sentry blog

ChangelogCodecovDashboardsDiscoverDogfooding ChroniclesEcosystemError MonitoringEventsGuest PostsMobileOpen SourcePerformance MonitoringRelease HealthResourceSDK UpdatesSentry
© 2024 • Sentry is a registered Trademark
of Functional Software, Inc.