--- title: "Alert Action" description: "Learn about the alert action UI component." url: https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action/ --- # Alert Action | Sentry Docs An alert action component allows users to specify details specific to your service that can help route alerts when they're triggered in Sentry. The schema is defined on the integration details page, and when users set up an alert action with your integration, the associated UI components will be presented to them. The details they provide will be included in the following alert webhook payloads, when the alerts fire: * [Issue Alert](https://docs.sentry.io/integrations/integration-platform/webhooks/issue-alerts.md) * [Metric Alert](https://docs.sentry.io/integrations/integration-platform/webhooks/metric-alerts.md) * [Activity Alert](https://docs.sentry.io/integrations/integration-platform/webhooks/activity-alerts.md) ## [Schema](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#schema) ```json { "elements": [ { "type": "alert-rule-action", "title": , "settings": { "type": "alert-rule-settings", "uri": , "required_fields": >, "optional_fields": >, "description": } } ] } ``` ## [Attributes](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#attributes) * `title` - (Required) The title shown in the UI component. * `uri` - (Required) Sentry will make a POST request to the URI when the User submits the form. If the services fails to process the request (status code >= 400), this component will bubble up the error to the User with the provided response text. Check out our [URI Guidelines](https://docs.sentry.io/integrations/integration-platform/ui-components.md#uri-guidelines) documentation for formatting help. * `required_fields` - (Required) List of [FormField](https://docs.sentry.io/integrations/integration-platform/ui-components/formfield.md) components the User is required to complete. * `optional_fields` - (Optional) List of [FormField](https://docs.sentry.io/integrations/integration-platform/ui-components/formfield.md) components the User may complete. * `description` - (Optional) Text that will be displayed above the form. Limited to 140 characters. ## [Example](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#example) ```json { "elements": [ { "type": "alert-rule-action", "title": "Create a kanban item for MyApp", "settings": { "type": "alert-rule-settings", "uri": "/sentry/alert-action", "required_fields": [ { "type": "select", "label": "Ticket Type", "name": "ticket_type", "options": [ ["feat", "Feature"], ["bug", "Bug"], ["task", "Task"] ] }, { "name": "runbook", "type": "text", "label": "Runbook" }, { "type": "select", "label": "Assignee", "name": "assignee", "uri": "/sentry/alert-action/options/teams/" } ] } } ] } ``` ## [Settings Request Format](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#settings-request-format) When a user saves an alert rule with your alert action, Sentry sends a `POST` request to the settings `uri`, so you can validate what they entered. The request is signed with the `Sentry-App-Signature` header (see [Verifying Requests](https://docs.sentry.io/integrations/integration-platform/ui-components.md#verifying-requests)). ```json { "fields": [ { "name": "ticket_type", "value": "feat" }, { "name": "runbook", "value": "Follow up in #triage-feature-requests with sales if this is actionable." }, { "name": "assignee", "value": "team:789" } ], "installationId": } ``` ### [Attributes](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#attributes-1) * `fields` - The values the user entered, as a list of `name` and `value` pairs. This is the same format as the `settings` in alert webhooks. * `installationId` - The ID of the installation associated with the request Respond with a `2xx` status code to accept the settings. To reject them, respond with a status code of `400` or higher and a `message` in the JSON response body. Sentry shows the message to the user, prefixed with your integration's name, and doesn't save the alert rule. See [Surfacing Errors](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#surfacing-errors) for the response format. ## [Issue Alert Request Format](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#issue-alert-request-format) When an issue alert fires, your service will need to read the settings from the alert payload. The `settings` are in `data.issue_alert.settings`. Check out the full [Issue Alert webhook documentation](https://docs.sentry.io/integrations/integration-platform/webhooks/issue-alerts.md) for more information. ```json { ... "data": { ... "issue_alert": { ... "settings": [ { "name": "ticket_type", "value": "feat" }, { "name": "runbook", "value": "Follow up in #triage-feature-requests with sales if this is actionable." }, { "name": "assignee", "value": "team:789" }, ] } } } ``` ## [Metric Alert Request Format](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#metric-alert-request-format) When a metric alert fires, your service will need to read the settings from the alert payload. The `settings` are in `data.metric_alert.alert_rule.triggers[].actions[].settings`. An alert rule can have several triggers, and each trigger can have several actions with different settings. To find yours: 1. For `metric_alert.critical` and `metric_alert.warning` webhooks, pick the trigger whose `label` matches the webhook action (`critical` or `warning`). 2. In that trigger's `actions`, pick the action whose `sentry_app_installation_uuid` matches `installation.uuid` in the webhook body. Check out the full [Metric Alert webhook documentation](https://docs.sentry.io/integrations/integration-platform/webhooks/metric-alerts.md) for more information. ```json { ... "data": { ... "metric_alert": { ... "alert_rule": { ... "triggers": [ ... { ... "label": "critical", "actions": [ { ... "sentry_app_installation_uuid": "", "settings": [ { "name": "ticket_type", "value": "bug" }, { "name": "runbook", "value": "Check the docs (https://example.com/runbook/456) before picking this one up." }, { "name": "assignee", "value": "team:123" }, ] } ] } ] } } } } ``` ## [Activity Alert Request Format](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#activity-alert-request-format) When an activity alert fires, your service will need to read the settings from the alert payload. The `settings` are in `data.alert.settings`. Check out the full [Activity Alert webhook documentation](https://docs.sentry.io/integrations/integration-platform/webhooks/activity-alerts.md) for more information. ```json { ... "data": { ... "alert": { ... "settings": [ { "name": "ticket_type", "value": "task" }, { "name": "runbook", "value": "Check if this issue is related to mobile exclusively." }, { "name": "assignee", "value": "team:456" }, ] } } } ``` ## [Surfacing Errors](https://docs.sentry.io/integrations/integration-platform/ui-components/alert-action.md#surfacing-errors) When a request to your service fails, you can show the user a specific error message in [sentry.io](https://sentry.io) by responding with a JSON body in this shape: ```json { "message": "Channel no longer exists!" } ``` Sentry forwards your service's status code and shows the `message` from the response body. If you return an error status without a `message`, the user sees a generic error message. If your service doesn't respond at all (for example, the request times out), Sentry returns a `502`. In all cases, the user's action won't complete until the request succeeds.