Triggers - EasyAlert

Overview

Every workflow starts with a trigger — the event or schedule that kicks off execution. EasyAlert supports four trigger types to cover both reactive and proactive automation.

Incident Events

Automatically respond when incidents are created, acknowledged, resolved, escalated, or reassigned

Webhook

Accept HTTP POST requests from external systems — CI/CD pipelines, monitoring tools, custom scripts

Scheduled (Cron)

Run workflows on a recurring schedule using standard cron expressions

Manual

Execute workflows on-demand from the UI or API with optional input variables

Incident Event Triggers

Incident event triggers fire automatically when an incident lifecycle event occurs. Use trigger conditions to filter which incidents activate the workflow.

incident.created
incident.acknowledged
incident.resolved
incident.escalated
incident.reassigned

Fires when a new incident is created from any source — webhook integration, API call, or manual creation.Common use cases:

Auto-remediate known issues (restart service, scale deployment)
Enrich incidents with additional data from external systems
Route incidents to the right team based on service or tags

Trigger Conditions

Conditions filter which incidents activate the workflow. Without conditions, every matching event triggers the workflow. Condition Structure: Each condition evaluates a field against a value using an operator. Conditions are grouped with AND (all) or OR (any) logic. Available Fields:

Field	Description	Example Value
`severity`	Incident severity level	`critical`, `high`, `medium`, `low`
`status`	Incident status	`triggered`, `acknowledged`, `resolved`
`service`	Service that generated the incident	`payment-api`, `auth-service`
`source`	Integration source	`prometheus`, `datadog`, `custom`
`host`	Affected hostname	`web-01.prod.internal`
`teamId`	Assigned team ID	`team-uuid-here`
`tags.*`	Any incident tag by key	`tags.environment = production`

Operators: equals, notEquals, contains, startsWith, endsWith, in, notIn, exists, notExists, matches (regex), and more. See the Node Types guide for the complete operator list.

Example: Critical Production Incidents Only

Trigger conditions:

Logic: all (AND)
- severity equals critical
- tags.environment equals production

This workflow only fires for critical incidents in the production environment. A high-severity staging incident won’t trigger it.

Webhook Triggers

Webhook triggers let external systems start a workflow by sending an HTTP POST request. This is ideal for integrating with CI/CD pipelines, custom monitoring tools, or any system that can make HTTP calls.

Enable Webhook Trigger

In the workflow designer, set the trigger type to Webhook in the Trigger node inspector.

Generate Webhook Key

Click Generate Webhook Key. This creates a unique URL and a bearer token (secret).

Copy Credentials

Copy the Webhook URL and Secret. The secret is shown only once.

Configure Your Source

Set up your external system to POST to the webhook URL with the Bearer token.

Webhook URL format:

POST https://api.easyalert.io/api/v1/automation/webhooks/{webhookKey}

Example request:

curl -X POST https://api.easyalert.io/api/v1/automation/webhooks/wh_abc123 \
  -H "Authorization: Bearer your_webhook_secret" \
  -H "Content-Type: application/json" \
  -d '{"variables": {"deployment": "v2.1.0", "environment": "production"}}'

The webhook secret is displayed only once when generated. If you lose it, you must regenerate the webhook key (which also changes the URL). See the Webhook API guide for full API reference.

Security features:

Feature	Detail
Rate Limit	60 requests per minute per webhook key
Idempotency	Duplicate payloads within 5 minutes return a cached result
Authentication	Bearer token (bcrypt-hashed server-side)
Custom Idempotency Key	Optional `X-Idempotency-Key` header for explicit deduplication

Scheduled Triggers (Cron)

Cron triggers run workflows on a recurring schedule using standard 5-field cron expressions. Cron Format:

┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, 0 = Sunday)
│ │ │ │ │
* * * * *

Supported syntax:

Syntax	Meaning	Example
`*`	Every value	`* * * * *` = every minute
`*/N`	Every N values	`/5 * * *` = every 5 minutes
`N-M`	Range	`9-17 * * * *` = hours 9 through 17
`N,M,O`	List	`1,15 * * * *` = minutes 1 and 15

Common presets:

Preset	Expression	Description
Every 5 minutes	`/5 * * *`	Run 12 times per hour
Every hour	`0 * * * *`	Top of every hour
Every day at midnight	`0 0 * * *`	Once daily at 00:00
Every Monday at 9 AM	`0 9 * * 1`	Weekly on Monday morning
First of month at noon	`0 12 1 * *`	Monthly on the 1st at 12:00

The workflow designer includes a cron validator that shows a human-readable description of your expression (e.g., “Every Sunday at midnight”) and the next 5 run times.

Custom Expression Examples

Expression	Meaning
`30 2 * * *`	Every day at 2:30 AM
`0 9-17 * * 1-5`	Every hour from 9 AM to 5 PM, weekdays only
`0 0 /2 *`	Every other day at midnight
`15 10 * * 0`	Every Sunday at 10:15 AM
`0 /4 * *`	Every 4 hours

Auto-Disable on Failure

If a cron-triggered workflow fails 5 consecutive times, it is automatically disabled to prevent runaway failures:

A banner appears on the workflow with the disable reason and timestamp
The cron schedule stops firing
You can re-enable the workflow from its settings after fixing the underlying issue

Auto-disable only affects cron triggers. Incident event and webhook triggers are not affected by consecutive failures.

Manual Triggers

Manual triggers let you execute a workflow on-demand from the UI or API. They’re useful for:

Testing workflows before activating event-based triggers
Running one-off automation tasks
Executing maintenance workflows that don’t need to be scheduled

Open the Workflow

Navigate to Automation > Workflows and open the workflow you want to execute.

Click Execute

Click the Execute button in the toolbar. Optionally provide input variables as JSON.

Monitor Execution

The execution starts immediately. You’re redirected to the execution detail page to monitor progress in real-time.

Manual execution requires the automation:execute permission. The workflow must be published but doesn’t need to be active (activated) — you can manually execute inactive workflows.

Template Variables

Template variables let you use dynamic data in your workflow — incident fields, webhook payloads, node outputs, and more. The syntax is {{variable.path}} with dot notation.

Incident Variables
Webhook Variables
Node Output Variables
Error Variables
ForEach Variables

Available when the trigger is an incident event:

Variable	Description	Example
`{{incident.id}}`	Incident ID	`INC-001`
`{{incident.title}}`	Incident title	`High CPU on web-01`
`{{incident.description}}`	Incident description	`CPU usage exceeded 90%`
`{{incident.severity}}`	Severity level	`critical`
`{{incident.status}}`	Current status	`triggered`
`{{incident.service}}`	Source service	`payment-api`
`{{incident.host}}`	Affected hostname	`web-01.prod`
`{{incident.teamId}}`	Assigned team ID	`team-uuid`
`{{incident.assignedTo}}`	Assigned user ID	`user-uuid`
`{{incident.createdAt}}`	Creation timestamp	`2024-01-15T10:30:00Z`
`{{incident.tags}}`	All tags as object	`{"env": "prod"}`
`{{incident.eventType}}`	Event that triggered	`incident.created`

Available when the trigger is a webhook. Variables come from the variables field in the POST body:

POST /webhooks/{key}
{
  "variables": {
    "deployment": "v2.1.0",
    "environment": "production",
    "commit": "abc123"
  }
}

Access with {{webhook.deployment}}, {{webhook.environment}}, {{webhook.commit}}.

Access outputs from previous nodes in the workflow:

Variable	Description
`{{nodes.<nodeId>.output}}`	Full output object
`{{nodes.<nodeId>.output.stdout}}`	SSH/Script stdout
`{{nodes.<nodeId>.output.stderr}}`	SSH/Script stderr
`{{nodes.<nodeId>.output.statusCode}}`	HTTP status code
`{{nodes.<nodeId>.output.body}}`	HTTP response body
`{{nodes.<nodeId>.status}}`	Node execution status
`{{nodes.<nodeId>.exitCode}}`	Exit code

Available inside Error Handler nodes:

Variable	Description
`{{error.message}}`	Error message
`{{error.nodeId}}`	Failed node ID
`{{error.actionType}}`	Failed action type
`{{error.exitCode}}`	Exit code
`{{error.statusCode}}`	HTTP status code
`{{error.output}}`	Full output from failed node

Available inside ForEach loop iterations:

Variable	Description
`{{foreach.item}}`	Current item value
`{{foreach.index}}`	0-based iteration index
`{{foreach.total}}`	Total items in collection

Use the Variable Picker (braces icon) in the workflow designer to browse and insert available variables. It shows all variables from the current context — incident fields, upstream node outputs, and loop variables.

Best Practices

Use trigger conditions to reduce noise

Without conditions, an incident.created trigger fires for every incident. Add conditions to filter by severity, service, or environment so the workflow only runs when it’s relevant.

Test webhooks with cURL before integration

Before connecting your CI/CD pipeline or monitoring tool, send a test request with cURL to verify the webhook URL and secret are correct. Check the execution in the UI to confirm variables are received.

Use cron presets for common schedules

The designer provides presets for common intervals. Use these instead of writing cron expressions from scratch to avoid syntax errors.

Prefer specific event triggers over broad ones

Instead of one workflow triggered by all incident events, create separate workflows for incident.created and incident.resolved. This keeps workflows focused and easier to debug.

Troubleshooting

Incident trigger not firing

Steps:

Verify the workflow is published and activated (both required)
Check trigger conditions — test with a broader filter first
Verify the incident event type matches (e.g., created vs acknowledged)
Check Automation > Executions for any runs that may have failed silently

Webhook returns 401 Unauthorized

Cause: Invalid or missing Bearer token.Steps:

Verify Authorization: Bearer <secret> header is included
Verify the secret matches — it was shown only once at generation
If unsure, regenerate the webhook key and use the new secret

Webhook returns 429 Too Many Requests

Cause: Rate limit exceeded (60 requests/minute per webhook key).Steps:

Reduce the call frequency from your source system
Use the X-Idempotency-Key header to deduplicate retries
If you need higher throughput, contact support

Cron trigger stops running

Cause: Auto-disabled after 5 consecutive failures.Steps:

Check the workflow for an auto-disable banner
Review recent execution failures in Automation > Executions
Fix the underlying issue (connection, credentials, action parameters)
Re-enable the workflow from its settings

Template variables resolve to empty

Cause: Variable path doesn’t match available data.Steps:

Use the Variable Picker to check available variables
Verify the variable path matches the data structure (e.g., {{incident.title}} not {{title}})
For node outputs, ensure the upstream node has actually executed
For webhook variables, verify the POST body includes the variables field

​Overview

Incident Events

Webhook

Scheduled (Cron)

Manual

​Incident Event Triggers

​Trigger Conditions

​Webhook Triggers

​Scheduled Triggers (Cron)

​Auto-Disable on Failure

​Manual Triggers

​Template Variables

​Best Practices

​Troubleshooting

Overview

Incident Event Triggers

Trigger Conditions

Webhook Triggers

Scheduled Triggers (Cron)

Auto-Disable on Failure

Manual Triggers

Template Variables

Best Practices

Troubleshooting