Operations | Monitoring | ITSM | DevOps | Cloud

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.

Application crashes have a significant impact on customer experience, which can adversely affect a company’s reputation and revenue. Error and crash reporting is a unique feedback mechanism that provides true data about the quality of their product. Developer teams that create games, mobile applications, IoT, and other high-performance applications need rich insights into application health to quickly and continuously fix software errors with minimal impact.

Joao Grassi — a .NET developer, front-end hobbyist, and friend of Sentry — likes .NET very much. So do we. With the help of one of Sentry’s top 10 SDKs, .NET developer teams process roughly half a billion .NET events every month. In this post, we strive for app security with Azure Key Vault and Sentry. By now, it’s not big news that ASP.NET Core is the future of web development with .NET.

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. In this post, we stretch technologies to their limits to see real-time data while handling traffic spikes.

In our Sentry for Data series, we explain precisely why Sentry is the perfect tool for your data team. The present post focuses on how we used Sentry to make debugging Apache Beam easier (and faster). Since its creation, Sentry has embraced a single vision: help all developer teams build the best software, faster. We want to give developers the information they need to resolve issues quickly, without having to dig through noisy log lines.

On any given day, we use rideshare apps to get from one place to another. We check public transportation apps to see when the next train is arriving at the station. We use streaming services to watch Frasier at the end of lo-ooo-ng work days. As part of engineering teams, we use application monitoring and cloud services (like CI and cloud infrastructure) to function, so that code changes seamlessly deploy into production.

Sentry helps developer teams build the most reliable software. Our help often manifests in two distinct forms: resolving issues in your product and ensuring that issue resolution fits seamlessly into existing workflows. We recently launched our Integration Platform, which allows developers to build publicly available tools on top of Sentry. For the launch, we built many new features, while also making it easier to use existing ones.