Sentry is full of engineers, so we know how painful it can be to deal with breaking changes caused by third party libraries. But we also know those third party libraries have to continually update and stay on top of their games, or they’ll become irrelevant. For that reason, we try to only introduce breaking changes when they’re really (really) required. Especially when those changes are made to an API surface.
Data pipelines and analytics tooling have become essential parts of modern businesses, so why are error monitoring and observability tooling for data tools still 10 years behind modern application development? Logs are just not good enough to make sure you can quickly and efficiently debug your errors.
More than a decade ago, a small piece of code that would eventually be called Sentry was born. When I wrote this code, I didn’t know much about open-source, so when it came down to licensing, I just grabbed the first reasonable suggestion thrown my way. That suggestion happened to be the BSD 3-Clause License. Fast forward to today, and a lot has changed.
It’s hard (if not impossible) to imagine production infrastructure without incidents. And service reliability can be highly dependent on how quickly and efficiently engineers are able to tackle these incidents. Reliability engineers are often faced with four questions... Sometimes the answers to these questions are surprising.
Welcome to our series of blog posts about things Sentry does that perhaps we shouldn’t do. Don’t get us wrong — we don’t regret our decisions. We’re sharing our notes in case you also choose the path less traveled.
Ah, August and September — two months that are part of an eleven way tie for first place in our favorite month of the year rankings (sorry, February). We’re currently heads down working on our APM functionality.
In March, we awarded Sentry’s Open Source Grant to Latinx non-profit Techqueria. Here’s a look at their progress, six months later.
Last week, we spoke with a lot of folks at PagerDuty Summit, where we explored the power of error monitoring in a world that’s always on (or on-call). What a neat tweet. Throughout our conversations, one thing became clear: developers are seeking out increased efficiency — they want to minimize time to error detection and resolution. They want to know about issues, find the root cause, and fix them quickly so that they can move on to other things — like writing more code.
Whether it’s a computer game, IoT device, or high-performance backend, chances are you’re using a native language to develop this application. Hands down, by far the most popular choices today for native application development are C and C++. Okay, maybe not the most popular, but definitely the most prevalent. Some might even say “inevitable.”
When I started Sentry in 2008 as an open-source side-project, I was solving a problem for myself. I wanted visibility and alerting around what errors occurred and when. I wanted to take errors out of log files and into an easily digestible dashboard.
