Some steps in an alert's life need a person to decide: handing the alert to another operations center with a note about what was already checked, or calling an internal service to look something up. A custom alert action packages one of those steps into a button on the alert.
An administrator defines the action once — what it sends, where it goes, and what the responder has to type first. The responder then picks it from the Actions menu on any alert it applies to. Recipients and format are fixed by the definition, so the only decision left at 3 AM is what to write.
You build it with the same tool as the rest of Automation Actions — the difference is the trigger. Every other trigger fires on an event; this one waits for a person.
Read the alert → collect what the responder types → deliver it by email, REST call, or channel message.
Go to Settings → Shared Resources → Automation Actions → New, and pick User runs a custom alert action as the trigger. To make the action appear only on one team's alerts, create it under that team instead of at the organization level.
A custom alert action can be limited to the alerts it makes sense for, with conditions on the alert's Field, Severity, Provider, and — for an organization-level action — Team. Set them on the whole action, on an individual delivery step, or both. The Variables input step takes no conditions: it always runs, so every delivery step has its values.
Conditions decide which alerts offer the action, and which steps run when a responder picks it. An action for Datadog alerts only never appears on a PagerDuty alert; an action that emails one team for SEV0 and another for everything else carries that split as two Send email steps with their own conditions.
A custom alert action has a fixed shape:
Each field in a Variables input step has:
| Field | What it is |
|---|---|
| Key | How you refer to the value in the steps below — e.g. customer_name. Starts with a letter; letters, numbers, and underscores only, up to 100 characters. |
| Label | What the responder sees above the input box — e.g. Customer ID. |
| Type | String, Long text, Number, Boolean, or Dropdown list. A dropdown list carries its own set of choices. |
| Required | Whether the responder must fill it in before the action can run. |
| Default value | Optional. What the box starts with when the dialog opens. For a dropdown list it has to be one of the choices. |
The delivery steps can then use these values as placeholders anywhere they accept them — an email subject and body, a REST URL, headers, query, or JSON body — alongside the usual alert placeholders like {{ alert_title }} and {{ alert_severity }}. Your own fields are written with a prefix, as {{ __variables__.customer_name }}. Pick both kinds from the placeholder list in the editor rather than typing them by hand.
