Engineering
Monitoring our Local Development Environment with Sentry
Is your organization's local development environment plagued with issues? Read on how you can use Sentry to monitor it and help you solve issues quickly.
Engineering
Distributed Tracing 101 for Full Stack Developers
In today’s modern web stack it’s anything but. Full stack developers are expected to write JavaScript executing in the browser, interop with multiple database technologies, and deploy server side code on different server architectures (e.g. serverless). Without the right tools, understanding how a user interaction in the browser cascades into a 500 server error deep in your server stack is nigh-impossible. Enter: distributed tracing.
Engineering
Instrumenting Our Frontend Test Suite (...and fixing what we found)
Adding Instrumentation to Jest Here at Sentry, we like to dogfood our product as much as possible. Sometimes, it results in unusual applications of our product…
Engineering
Dogfooding Chronicles: Never Be Content With Your Content (Security Policies)
A Content Security Policy (CSP) lets a browser know which content sources are to be trusted — and which aren’t. Learn how to update your CSP and protect your application.
Engineering
Slow and Steady: Converting Sentry’s Entire Frontend to TypeScript
Recently, Sentry converted 100% of its frontend React codebase from JavaScript to TypeScript. This year-long effort spanned over a dozen members of the engineering team, 1,100 files, and 95,000 lines of code.
Engineering
Using Sentry Performance To Make Sentry Performant
Like many companies, Sentry uses feature flags to determine when certain users see certain features. Recently, we decided to switch our feature flag software…
Engineering
Issue Detail Performance Improvements
One of Sentry’s most-trafficked pages is our issue details page, as it helps our customers understand the root cause of an error. For those of you who are new…
Engineering
Verifying Large Refactors in Production with Sentry
Recently we used Sentry to ensure we didn’t break Sentry while doing a large code refactoring project.
Engineering
Finding and Fixing Django N+1 Problems
Sentry now detects N+1 issues. Learn more about how to find and fix Django N+1 problems here.
Engineering
Go-Getting Lazy-Loading
In our latest edition of the Dogfooding Chronicles, we use Performance to motivate lazy-loading user-facing data.
Engineering
Handling GraphQL Errors Using Sentry
When GraphQL queries go wrong, the focus is usually on handling the returned exception. Learn how to take the original GraphQL request & translate it into a more informative response with Sentry.
Engineering
Dogfooding Chronicles: Thinking Backward, Moving Forward
In part two of Dogfooding Chronicles, our team used all available resources — Discover, Metric Alerts, and our new Performance offering — to track a slow-loading frontend issue back to its backend origins.
Engineering
Dogfooding Chronicles: Tracing the path from “It’s Slow” to “What’s Slow”
In part one of Sentry’s Dogfooding Chronicles, find out how we used Performance’s application monitoring features to keep a slow product demo from demoralizing the team.
Engineering
How we grew Sentry's monthly active users by rethinking invitations
At its core, Sentry is a tool that alerts you to defects in your production software. But it does more than blast stack traces into your inbox: Sentry provides powerful workflows to help your team determine root cause, triage issues to your team, and keep tabs on ongoing concerns with comments and notifications. At the end of 2019, the Growth team made it our mission to make it easier for our users to invite their teammates to join them on Sentry. Our theory: improving the user experience of inviting users, as well as democratizing the process to include all team members would lead to a significant increase in team-wide adoption. (Narrator: it did.)
Engineering
How to Mutate Data in a System Designed for Immutable Data
Sentry’s growth led to increased write and read load on our databases, and, even after countless rounds of query and index optimizations, we felt that our databases were always a hair’s breadth from the next performance tipping point or query planner meltdown. Increased write load also led to increased storage requirements (if you’re doing more writes, you’re going to need more places to put them), and we were running what felt like an inordinate number of servers with a lot of disks for the data they were responsible for storing. Here’s a look at how we attempted to understand which database system was right for us and how we adapted our approach when we encountered some unexpected challenges.
