Note: If you've configured Alert Rule Actions, you should refer to the those setup instructions instead.
- Ensure this application is running (
make serve-typescript
ormake serve-python
) and has been installed on your organization in Sentry. - Create a new alert (Alerts > Create Alert)
- To setup a test issue alert, select 'Issues' then 'Set Conditions'
- Give the rule a name, and a the 'A new issue is created' trigger
- In the action dropdown, select 'Send a notification via an integration'
- In the integration dropdown, select your integration.
- To setup a test metric alert, select 'Number of Errors' then 'Set Conditions'
- Set the critical, warning and resolved thresholds to
3
,2
and1
respectively - Click 'Add Action' and select the trigger you'd like to test (e.g. 'Critical Status')
- Click the default action (e.g. 'Email') and select your integration
- Remember to give your rule a name
- Set the critical, warning and resolved thresholds to
- Save the alert rule.
- To trigger your issue alert:
- Go to your frontend webpage (http://localhost:3000 by default)
- Trigger a new issue by clicking 'Send Error to Sentry'
- Wait for a moment, while the
event_alert.triggered
webhooks are sent to your application.
- To trigger your metric alerts:
- Go to your frontend webpage (http://localhost:3000 by default)
- Trigger a new issue by clicking 'Send Error to Sentry' and refresh the page.
- Do this an appropriate number of times to trigger the appropriate incident (e.g. twice for a warning, thrice for a critical)
- Wait for a moment, while the
metric_alert
webhooks are sent to your application.
- To test alert triggers repeatedly while developing, we recommend take advantage of the ngrok's inspection interface (located by default on http://localhost:4040/inspect/http)
- When any of these alerts have been triggered, a new item with the corresponding alert information should appear in your kanban view.
If you monitor server logs during the above alert rule webhooks test, you should see something similar to the following:
# Triggered when Sentry renders your async settings form fields
Authorized: Verified request came from Sentry
Populating user options in Sentry
# Allows the Sentry User to save the alert rule
Successfully validated Sentry alert rule
# Logs the successful handling of the relevant webhook
Created item from issue alert trigger
Warning item from metric alert warning trigger
Modified item from metric alert critical trigger
Modified item from metric alert resolved trigger
All the authorization logs are coming from middleware which verifies the request signature with the shared secret:
The 'Populating user options' log comes from the select field we specify in the schema:
- Integration Schema (Look at the blob under
elements[1].settings.required_fields
)
It tells Sentry what endpoint to ping and use to populate options in a Select field.
The 'Successful validation' log comes from Sentry pinging another endpoint we specifiy in the schema
- Integration Schema (Look at the blob under
elements[1].uri
)
Here, we're validating the settings that the user sent to our application. Then, we tell Sentry whether or not it should approve the changes to the alert rule. If something is incorrect, we can surface error messages directly to the user in Sentry.
The 'Created/Modified item' logs come from the consumption of the alert webhooks.