We get it — errors suck. And you don’t want to spend too much of your time fixing them, dealing with them, investigating them, etc. In our Workflow blog post series, we’ll help you optimize your, well, workflow from crash to resolution.

Sentry is more than just error tracking. Sentry helps you maintain the quality of your code and work more efficiently with your team to improve the user’s experience. Merging Sentry into your existing workflow — specifically the alert, triage, and resolution phases — provides the insight to work at your highest efficiency and gain accountability throughout your application lifecycle.

In this post, we’re focused on the alert phase, with an emphasis on custom alerts. Next time, we’ll talk about the triage phase. And, as you can probably guess, the resolution phase will resolve (heh) the series.

Alerts

Sentry’s notifications give immediate visibility into the impact of errors on your users and why you are being alerted. Alerts explain why you’re being notified and uncover the error type. Instead of reacting to a series of problems run rampant, each developer on your team can proactively decide the appropriate next step, nesting iteration directly within the existing development workflow.

Sentry has SDKs that support most languages — virtually all of them, to be precise — and you’ll want to set that up first. Getting started with Sentry is a three-step process:

Use issue graphs to understand the frequency, scope, and impact of errors and prioritize what needs to be fixed.

Fix multiple instances at once and streamline the process of receiving notifications by grouping related errors by the stack trace.

Drill into the issue to see all the details about the error, including owners, environments, and tag heat maps.

Organizations that configure at least one alert rule are four times more likely to successfully triage that issue and 13 times more likely to resolve an issue.

Custom alerts

Sentry automatically sets up a default alert rule that notifies you any time an error is first encountered. The first time a new issue is generated by an error, we’ll notify you of it via whatever services you have connected to Sentry.

The default alert is great, sure, but you can also customize alerts according to your organization’s specific workflow, stack, communication style, and objectives. Actually, organizations that configure at least one alert rule are four times more likely to successfully triage that issue and 13 times more likely to resolve an issue.

By tailoring alert rules and integrating into the tools you already use, you can receive alerts when (and if) you want them, without disruption.

Alerts are configured per project and are based on the rules defined for that project. To modify the rules visit your Project Settings > Alerts > Rules tab. On this page, you’ll see a list of all active rules, including conditions and actions, which you can modify.

My favorite part of Sentry is collecting related errors into a single item. Seeing only my 30 issues out of thousands makes resolution easy. With Sentry, I can fix a million problems all at once.

Contextual alerts can lead to increased accountability for the customer’s experience. Visibility into previously hidden issues means a more timely remediation process in your existing workflow and a much higher signal-to-noise ratio (plus happier developers).

Sentry provides open source error tracking that shows you every crash in your stack as it happens, with the details needed to prioritize, identify, reproduce, and fix each issue. It also allows your users to send feedback that helps your support team respond appropriately.

Each month we process billions of exceptions from the most popular products on the internet.