Triggers - AppSignal Documentation

The triggers commands manage anomaly detection triggers: alerts that open when a metric crosses a threshold you define. Each command targets one application, by name and environment (--app "MyApp" --environment production) or by ID (--app-id <APP_ID>, the long hexadecimal app ID from appsignal-cli apps list). The --environment flag is only needed when several apps share a name, and each command uses your default organization unless you pass --org. See Apps and organizations.

These are anomaly detection triggers on metrics. For triggers built from log lines, see Logs.

List triggers

Shell

appsignal-cli triggers list --app "MyApp" --environment production

Filter the list by metric name or tags when you are reviewing a specific group of triggers:

Shell

appsignal-cli triggers list --app "MyApp" --environment production --metric-name response_time
appsignal-cli triggers list --app "MyApp" --environment production --tag hostname=web-1

Create a trigger

A trigger watches one metric field and opens an alert when it crosses a threshold:

Shell

appsignal-cli triggers create --app "MyApp" --environment production \
  --name "Slow web requests" \
  --metric-name response_time --kind Advanced --field mean \
  --comparison-operator ">" --condition-value 500 \
  --warmup-duration 5 --cooldown-duration 2 \
  --description "Alert when mean response time stays above 500ms"

These flags are required:

Flag	Description
`--metric-name <name>`	The metric to monitor
`--kind <kind>`	Trigger kind, e.g. `Advanced`, `Performance`, or `HostCPUUsage`
`--field <field>`	Field to compare: `count`, `counter`, `gauge`, `mean`, `p90`, or `p95`
`--comparison-operator <op>`	One of `>`, `>=`, `<`, `<=`, `==`, or `!=`
`--condition-value <number>`	Threshold to compare against
`--warmup-duration <minutes>`	How many minutes the metric must stay above or below the threshold before opening an alert
`--cooldown-duration <minutes>`	How many minutes the metric must stay recovered before closing an alert

These flags are optional:

Flag	Description
`--name <text>`	Display name (defaults to the metric name)
`--description <text>`	Description shown with the trigger
`--notifier-ids <list>`	Comma-separated notifier IDs to attach
`--tag <key=value>`	Tag filter (repeat the flag, or comma-separate)
`--dashboard-id <id>`	Dashboard to link from notifications
`--no-match-is-zero`	Treat missing datapoints as 0
`--format <format>`	Value format, e.g. `duration`, `number`, or `percent`
`--format-input <unit>`	Input unit for size formats, e.g. `byte` or `kilobyte`

Update a trigger

Update a trigger by its --id from triggers list. An update archives the existing trigger and creates a replacement linked to it. Pass the full trigger definition when updating. Start from the current values in triggers list, then change the fields you want to retune:

Shell

appsignal-cli triggers update --id <TRIGGER_ID> --app "MyApp" --environment production \
  --name "Slow web requests" \
  --metric-name response_time --kind Advanced --field mean \
  --comparison-operator ">" --condition-value 750 \
  --warmup-duration 5 --cooldown-duration 2 \
  --notifier-ids <NOTIFIER_ID>

update accepts the same flags as create. Include optional values you want to keep, such as --notifier-ids, --tag, --dashboard-id, and --description.

Archive a trigger

Archiving a trigger also closes its associated alerts and incidents:

Shell

appsignal-cli triggers archive --id <TRIGGER_ID> --app "MyApp" --environment production

Next steps

A trigger opens an incident when the metric crosses the trigger threshold. Inspect those incidents with the incidents commands.

​List triggers

​Create a trigger

​Update a trigger

​Archive a trigger

​Next steps

List triggers

Create a trigger

Update a trigger

Archive a trigger

Next steps