Skip to main content
Triggers define when your agents run. An agent can have one or multiple triggers, allowing you to run the same logic on different events—like reviewing PRs when they’re opened and auditing documentation on a weekly schedule. Agent Diagram

Trigger Types

Agents support five trigger types:
EventDescription
pull_requestRuns when PRs are opened, updated, or reopened
pushRuns when commits are pushed to branches
scheduledRuns on a cron schedule
airflowRuns when Airflow pipelines fail
monitorRuns when data quality monitors detect issues
You can combine multiple triggers on a single agent. For example, run documentation updates on every PR and perform weekly audits via schedule.

Pull Request Triggers

The most common trigger type. Runs when pull request events occur on your repository.
triggers:
  - event: pull_request
    branches: ['main', 'develop']
    types: ['opened', 'synchronize', 'reopened']
    includes:
      - "models/**/*.sql"
      - "models/**/*.yml"
    auto_commit: false

Fields

event
"pull_request"
required
Specifies this is a pull request trigger.
branches
array
Branch patterns the PR must target. Defaults to ["*"] (all branches).
branches:
  - main
  - develop
  - "release/*"
types
array
PR event types that activate the trigger:
TypeDescription
openedPR was created
synchronizeNew commits pushed to PR
reopenedPR was reopened after being closed
types: ['opened', 'synchronize']
Most agents use opened and synchronize to review new code and updates.
includes
array
Glob patterns for file filtering. The trigger only fires if at least one changed file matches a pattern.
includes:
  - "models/**/*.sql"
  - "models/**/*.yml"
  - "macros/**"
If omitted, the trigger fires for all file changes.
auto_commit
boolean
Controls how the agent commits changes. Defaults to false.
ValueBehavior
falseCreates a new branch from the PR’s head and opens a new PR with changes. Safe for collaboration.
trueCommits directly to the PR’s branch. Can cause conflicts if others are also pushing.
Use auto_commit: true with caution. Direct commits to a PR branch can cause merge conflicts if multiple people are working on it.
repository
string
Repository in owner/repo format. Defaults to the current repository.

Example: PR Code Review

name: pr_reviewer

triggers:
  - event: pull_request
    branches: ['main']
    types: ['opened', 'synchronize']
    includes:
      - "models/**"
      - "macros/**"

prompt: |
  Review this PR for dbt best practices and potential issues.
  Post your findings as a helpful PR comment.

Push Triggers

Runs when commits are pushed directly to a branch (not via PR merge).
triggers:
  - event: push
    branches: ['main']
    includes:
      - "**/*.sql"

Fields

event
"push"
required
Specifies this is a push trigger.
branches
array
Branches to watch. Defaults to ["*"] (all branches).
includes
array
Glob patterns for file filtering. Only triggers if changed files match.
repository
string
Repository in owner/repo format. Defaults to the current repository.

Example: Post-Merge Documentation

name: post_merge_docs

triggers:
  - event: push
    branches: ['main']
    includes:
      - "models/**/*.sql"

prompt: |
  New models were merged to main. Update documentation for any 
  models that are missing descriptions or have outdated metadata.
  Create a PR with the documentation updates.

Scheduled Triggers

Runs on a recurring schedule defined by a cron expression.
triggers:
  - event: scheduled
    cron: "0 9 * * 1"
    branches: ['main']
    includes:
      - "models/**"

Fields

event
"scheduled"
required
Specifies this is a scheduled trigger.
cron
string
required
Cron expression defining when the agent runs. Uses standard 5-field format:
┌───────────── minute (0-59)
│ ┌───────────── hour (0-23)
│ │ ┌───────────── day of month (1-31)
│ │ │ ┌───────────── month (1-12)
│ │ │ │ ┌───────────── day of week (0-6, Sunday=0)
│ │ │ │ │
* * * * *
Common patterns:
ExpressionDescription
0 * * * *Every hour at minute 0
0 9 * * *Daily at 9 AM
0 9 * * 1Every Monday at 9 AM
0 0 1 * *First day of month at midnight
*/15 * * * *Every 15 minutes
0 9,17 * * 1-59 AM and 5 PM on weekdays
All schedules use UTC timezone. Use crontab.guru to build and validate expressions.
branches
array
Branches to check for changes. Defaults to ["*"].
includes
array
Glob patterns for file filtering. The agent only runs if files matching these patterns have changed since the last execution.
includes:
  - "models/**"
Use includes to avoid running expensive scheduled agents when nothing relevant has changed.
repository
string
Repository in owner/repo format. Defaults to the current repository.

Example: Weekly Documentation Audit

name: weekly_audit

triggers:
  - event: scheduled
    cron: "0 9 * * 1"  # Every Monday at 9 AM UTC
    branches: ['main']

prompt: |
  Perform a weekly documentation audit:
  1. Check all models in models/marts/ for missing descriptions
  2. Calculate overall documentation coverage
  3. Send a summary report to #data-documentation on Slack

tools:
  include:
    - slack_tool

Airflow Triggers

Runs when Airflow DAGs or tasks fail. Requires configuring Airflow to send failure callbacks to Buster.
triggers:
  - event: airflow
    type: dag_run_failed
    includes:
      - "critical_pipeline"
      - "daily_refresh"

Fields

event
"airflow"
required
Specifies this is an Airflow trigger.
type
string
required
The Airflow event type:
TypeDescription
dag_run_failedEntire DAG run failed
task_instance_failedIndividual task failed
includes
array
Filter by DAG or task names. Only triggers for matching names.
includes:
  - "critical_pipeline"
  - "data_quality_*"
repository
string
Repository in owner/repo format. Defaults to the current repository.

Airflow Configuration

To send failure events to Buster, configure your Airflow DAG with a failure callback:
import requests

def notify_buster_on_failure(context):
    requests.post(
        "https://api.buster.so/api/v2/public/airflow/events",
        headers={
            "Authorization": f"Bearer {BUSTER_API_KEY}",
            "Content-Type": "application/json"
        },
        json={
            "event_type": "dag_run_failed",
            "dag_id": context['dag'].dag_id,
            "task_id": context['task'].task_id,
            "execution_date": str(context['execution_date']),
            "error_message": str(context.get('exception', 'Unknown error'))
        }
    )

# Add to DAG default_args
default_args = {
    'on_failure_callback': notify_buster_on_failure,
}

Example: Pipeline Failure Handler

name: pipeline_failure_handler

triggers:
  - event: airflow
    type: dag_run_failed
    includes:
      - "critical_pipeline"

prompt: |
  An Airflow DAG has failed. Investigate:
  1. Check the error message from the trigger context
  2. Look for related models in the repository
  3. Create a GitHub issue with investigation steps
  4. Alert #data-incidents on Slack

tools:
  include:
    - slack_tool

Monitor Triggers

Runs when data quality monitors detect issues like schema changes, data anomalies, or stale data.
triggers:
  - event: monitor
    types: ['schema_drift', 'freshness']
    severity: ['medium', 'high']

Fields

event
"monitor"
required
Specifies this is a monitor trigger.
types
array
Filter by monitor types. Only triggers for matching monitor types.
TypeDescription
schema_driftDatabase schema changes (columns added/removed, type changes)
json_driftStructural changes in JSONB/JSON columns
volume_anomalyUnusual data volume patterns
freshnessData staleness exceeding thresholds
types: ['schema_drift', 'json_drift']
severity
array
Filter by alert severity. Only triggers for matching severity levels.
SeverityDescription
lowMinor changes, informational
mediumNotable changes requiring attention
highCritical changes requiring immediate action
severity: ['medium', 'high']
Use severity filters to avoid alert fatigue. Reserve high severity triggers for critical response agents.
repository
string
Repository in owner/repo format. Defaults to the current repository.

Context Variables

Monitor triggers provide context variables you can use in your prompt:
VariableDescription
{{monitor.name}}Name of the monitor that triggered
{{run.severity}}Severity level (low, medium, high)
{{run.reason}}Human-readable description of what triggered the alert
{{details.changes}}Structured data about what changed
For schema drift, the details.changes object includes:
  • added — New columns or tables detected
  • deleted — Removed columns or tables
  • modified — Changed column types or properties

Example: Schema Drift Handler

name: schema_drift_handler
description: Responds to schema drift alerts

triggers:
  - event: monitor
    types: ['schema_drift']
    severity: ['medium', 'high']

prompt: |
  A schema drift has been detected in the data warehouse.
  
  **Monitor**: {{monitor.name}}
  **Severity**: {{run.severity}}
  **Reason**: {{run.reason}}
  
  **Changes Detected**:
  {{#each details.changes.added}}
  - ADDED: {{this.path}}
  {{/each}}
  {{#each details.changes.deleted}}
  - DELETED: {{this.path}}
  {{/each}}
  
  Analyze these changes and:
  1. Determine if this is expected (deployment, migration) or unexpected
  2. If unexpected, investigate potential impacts on downstream models
  3. Update YAML documentation if needed
  4. Summarize findings and recommend next steps

tools:
  include:
    - slack_tool

Example: Freshness Alert Handler

name: freshness_handler
description: Investigates stale data alerts

triggers:
  - event: monitor
    types: ['freshness']
    severity: ['high']

prompt: |
  Data freshness alert detected.
  
  **Monitor**: {{monitor.name}}
  **Severity**: {{run.severity}}
  **Reason**: {{run.reason}}
  
  Investigate this freshness issue:
  1. Check when the table was last updated
  2. Look for recent pipeline failures in Airflow
  3. Check source system status
  4. Alert #data-incidents on Slack with findings

tools:
  include:
    - slack_tool

Multiple Triggers

An agent can have multiple triggers to handle different scenarios:
name: documentation_maintainer

triggers:
  # Update docs when PRs change models
  - event: pull_request
    types: ['opened', 'synchronize']
    includes:
      - "models/**/*.sql"
  
  # Weekly comprehensive audit
  - event: scheduled
    cron: "0 9 * * 1"
    branches: ['main']
  
  # Post-merge updates
  - event: push
    branches: ['main']
    includes:
      - "models/**/*.sql"

prompt: |
  Maintain documentation for dbt models.
  
  If triggered by a PR: Update docs for changed models only.
  If triggered by schedule: Audit all models for missing docs.
  If triggered by push: Ensure merged changes have complete docs.

Best Practices

Use File Filters

Always use includes to scope triggers to relevant files:
# Good: Only triggers on SQL changes
triggers:
  - event: pull_request
    includes:
      - "models/**/*.sql"

# Avoid: Triggers on every file change
triggers:
  - event: pull_request

Choose the Right Trigger Type

Use CaseTrigger
Code review, validationpull_request
Post-merge automationpush
Periodic audits, reportingscheduled
Pipeline failure responseairflow
Data quality alertsmonitor

Stagger Scheduled Agents

Avoid running multiple expensive agents at the same time:
# Agent 1: Monday 9 AM
triggers:
  - event: scheduled
    cron: "0 9 * * 1"

# Agent 2: Monday 10 AM (staggered)
triggers:
  - event: scheduled
    cron: "0 10 * * 1"

Combine Triggers for Coverage

Use multiple triggers to catch changes at different stages:
triggers:
  # Catch issues during review
  - event: pull_request
    types: ['opened', 'synchronize']
    includes: ["models/**"]
  
  # Catch anything that slipped through
  - event: scheduled
    cron: "0 9 * * *"
    branches: ['main']