We’re continuing our expansion into Native and Mobile by adding NDK support to our Android libraries so you’ll be able to trace bugs all the way into native libraries. At the same time we’ve brought the Android SDK into our unified API framework.
This year we introduced the Sentry Integration Platform, which allows 3rd-party developers to build integrations that connect Sentry with their software. More recently we launched Internal Integrations, which lets developers combine Sentry with their internal tools to support their own custom workflows.
In a world where companies’ security teams are notoriously—and rightly—paranoid, we’re pleased to announce that Sentry has recently received its SOC 2 Type I compliance certification. Having met this important industry standard on the effectiveness of a company’s internal controls around information security, our existing and future customers can be confident about their data security and integrity with Sentry.
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.
