At Sentry, we’re always looking for innovative ways to dogfood our product. Over the last year we added Sentry’s error monitoring to our developer environment so that we could better understand the health of it. In this blog post I’m going to touch on how fragile local development environments can be, how we brought observability into what’s happening by introducing Sentry, and what outcomes it has driven for our engineering organization.
For many engineering leaders, measuring their team’s impact can be hard to quantify and a face:palm process, filled with searching through logs and exporting data sets to cobble together a report that most people won’t even look at twice. And let’s be honest, if you wanted to spend time making reports, you wouldn’t have become a developer.
To give you enough notice to fix an issue before it escalates, we’re evolving our alerts and making them more proactive with Change and Crash Rate Alerts. So when your application experiences a change from the norm or a dip in crash-free sessions, Sentry will (smartly) alert you via Slack, Teams, PagerDuty, or old-fashioned email.
Given the millions of registered Unity developers worldwide, Unity is arguably the most popular engine used to develop games. But, whether you’re building the latest FPS or a turn-based classic, you need visibility in how your game is performing on a gamer’s device. More than 800 game development and platform companies rely on Sentry, from OutFit7 to Riot, Epic Games, and Unity.
Sentry is an open source company. We started out in 2008 as a small open source side project, and we grew within the community for years before commercializing in 2012. We’ve worked hard to keep our full product as open source as possible, while scaling as a business. Considering our commitment to open source, we are grateful to be able to give back to the community (and what better time than during Hacktoberfest, amirite?). (P.S.
