Triggers

What triggers are

Triggers let your node run on a schedule or in response to events, without waiting for a human to send a message. A triggered execution fires at defined intervals (hourly, daily, custom cron) and has access to all node capabilities — memory, tools, RAG, and streaming.

Use triggers for daily briefings, periodic data checks, automated report generation, and monitoring tasks.

Reliability model

• At-least-once delivery — triggers are designed to fire at least once per scheduled interval. Your processing logic should be idempotent.
• Retry on failure — if a triggered execution fails, the platform retries with exponential backoff
• Logging — every trigger execution is logged with timestamps, input, output, token usage, and any errors

Thread strategy

Each trigger execution can create a new thread or reuse an existing one:

• New thread per run (default) — each execution is independent. Best for reports and one-shot tasks.
• Reuse thread — subsequent executions continue the same conversation. Best for monitoring scenarios where the node should remember previous checks.

Configuration

Configure a trigger through the dashboard or API by specifying a cron expression and an optional input message:

{
  "schedule": "0 9 * * MON-FRI",
  "input": "Generate the daily sales summary for today.",
  "threadStrategy": "new"
}

This trigger fires at 9:00 AM on weekdays and sends the specified input to the node.

Common pitfalls

• Daylight saving time — cron schedules use UTC. Account for DST shifts if you need local-time semantics.
• Overlapping runs — if an execution runs longer than the trigger interval, the next execution is queued. Configure appropriate intervals for long-running tasks.
• Idempotency — design your triggered workflows to be safe to run twice. At-least-once delivery means occasional duplicate executions are possible.

Next steps

• API Overview — endpoints and error model
• API Examples — copy-paste starters
• Triggers feature page — deeper overview