Being able to visualize errors in the Sentry dashboard is awesome, but it'd be no fun to constantly have to check the dashboard to see if things were going okay or not. That's where Sentry alerts come in. With Sentry, we can set up email alerts based on very customizable parameters to let us know when certain things are going wrong. We can do this via the alerts page in the Sentry dashboard.
Right now, we don't have any alerts set up. So let's create a new alert rule with the button here on the top right. Great. This presents us with the alert creation wizard and provides us with a number of different options to get started.
Let's set some conditions on how we'd like to be notified about issues. First, we can choose which environment this alert should be triggered on. I'll choose development here. as we'll be mostly working in the development environment using npm run dev.
In real life though, you'd probably want to receive the alerts about your production environment. All right, I'll leave team alone and I'll call the alert. Let's say example alert. In the next step here, we have a lot of control over when exactly we want to send the alert.
We can choose from a number of different triggers, including a new issue being created, the issue state changing from resolved to unresolved, and so on. I'll choose a new issue is created. Then we can filter down that event even further if we'd like, based on the age of the issue, how often it's occurred, the tags on the event, and a whole lot of other cool things. For our purposes, I'll just leave it blank.
Lastly, we can choose what actions to perform when the conditions are true. We could send notifications to certain people or send a notification to any legacy integrations. I'll select send notification to issue owners team or member. The default option here is issue owners.
Issue owners are determined by setting up rules based on certain file paths that errors occur in. tags, or request URLs. This allows you to assign certain portions of the code to certain people or certain teams. Issue owners are beyond the scope of this lesson, but you can learn more via the link to the Sentry docs in the description below.
The next option is to send it to all the members of a particular team. Or, lastly, we could send it to a particular person. I'll choose this option and send the alert. to myself.
Lastly, we could even perform more than one action at a time if we wanted to, but that's not necessary for us. Alright, for step number three, we can set an interval for how often the alert is sent. This is helpful so that we can continue to get reminders of the issue after the initial alert, but not get spammed every single time the error occurs. I'll go with the default 30 minutes, but as you can see, There are a number of other timing options to choose from here.
All right, now we can create the rule. Since we created the alert to only fire on new issues, let's now create a new issue. view, I'll create yet another button. And let's say this button will make us some toast.
Then on click, I'll call a function makeToast. Then Make Toast will be defined in Script Setup. But Make Toast will call a non-existent function SliceBread. After running npm run dev and running the development version of the application, here in the browser I'll click Make Toast.
And sure enough, in the console we see that SliceBread is not defined. And if I wait for just a minute... Yeah. you probably just heard my phone buzz in the background.
That was that email alert from Sentry coming in. If I open up my email client, yeah, here's that alert. The email provides much of the information found in the dashboard and includes a link to see more info. Also, notice the Setup and Slack button in the top right of the email.
That could be pretty handy if your team uses Slack. Finally, while issue alerts are super handy, You can also set up what's known as metric alerts to let you know when a metric crosses a certain threshold, such as a spike in the number of errors in a project or a change in a performance metric. In conclusion, you can see how handy alerts can be. Being able to visualize errors in the Sentry dashboard is awesome, but it'd be no fun to constantly have to check the dashboard to see if things were going okay or not.
That's where Sentry alerts come in. With Sentry, we can set up email alerts based on very customizable parameters to let us know when certain things are going wrong. We can do this via the alerts page in the Sentry dashboard. Right now, we don't have any alerts set up.
So let's create a new alert rule with the button here on the top right. Great. This presents us with the alert creation wizard and provides us with a number of different options to get started. Let's set some conditions on how we'd like to be notified about issues.
First, we can choose which environment this alert should be triggered on. I'll choose development here. as we'll be mostly working in the development environment using npm run dev. In real life though, you'd probably want to receive the alerts about your production environment.
All right, I'll leave team alone and I'll call the alert. Let's say example alert. In the next step here, we have a lot of control over when exactly we want to send the alert. We can choose from a number of different triggers, including a new issue being created, the issue state changing from resolved to unresolved, and so on.
I'll choose a new issue is created. Then we can filter down that event even further if we'd like, based on the age of the issue, how often it's occurred, the tags on the event, and a whole lot of other cool things. For our purposes, I'll just leave it blank. Lastly, we can choose what actions to perform when the conditions are true.
We could send notifications to certain people or send a notification to any legacy integrations. I'll select send notification to issue owners team or member. The default option here is issue owners. Issue owners are determined by setting up rules based on certain file paths that errors occur in.
tags, or request URLs. This allows you to assign certain portions of the code to certain people or certain teams. Issue owners are beyond the scope of this lesson, but you can learn more via the link to the Sentry docs in the description below. The next option is to send it to all the members of a particular team.
Or, lastly, we could send it to a particular person. I'll choose this option and send the alert. to myself. Lastly, we could even perform more than one action at a time if we wanted to, but that's not necessary for us.
Alright, for step number three, we can set an interval for how often the alert is sent. This is helpful so that we can continue to get reminders of the issue after the initial alert, but not get spammed every single time the error occurs. I'll go with the default 30 minutes, but as you can see, There are a number of other timing options to choose from here. All right, now we can create the rule.
Since we created the alert to only fire on new issues, let's now create a new issue. view, I'll create yet another button. And let's say this button will make us some toast. Then on click, I'll call a function makeToast.
Then Make Toast will be defined in Script Setup. But Make Toast will call a non-existent function SliceBread. After running npm run dev and running the development version of the application, here in the browser I'll click Make Toast. And sure enough, in the console we see that SliceBread is not defined.
And if I wait for just a minute... Yeah. you probably just heard my phone buzz in the background. That was that email alert from Sentry coming in.
If I open up my email client, yeah, here's that alert. The email provides much of the information found in the dashboard and includes a link to see more info. Also, notice the Setup and Slack button in the top right of the email. That could be pretty handy if your team uses Slack.
Finally, while issue alerts are super handy, You can also set up what's known as metric alerts to let you know when a metric crosses a certain threshold, such as a spike in the number of errors in a project or a change in a performance metric. In conclusion, you can see how handy alerts can be.