---
{
  "id": "platform.trigger.fire-events-and-debugging",
  "topic": "trigger",
  "title": "Trigger fire events and debugging",
  "locale": "en",
  "version": "2026-07-17",
  "summary": "Debug Trigger as four stages—match, queue, Agent execution, and recorded result—with canonical fire statuses and bounded retention.",
  "content": "Separate four stages: the resource event matched, dispatch entered the queue, the Agent executed the task, and a result was recorded. `get_trigger` exposes the rule, replacement lineage, fire count, and last-fire summary; fire-event query surfaces provide recent execution detail. A successful create or match is not proof of successful Agent execution.\n\nCanonical run-result statuses are `success`, `partial`, `failed`, `skipped`, `timeout`, and `unknown`. For a no-fire report, check active/paused/cancelled state, source type, event type or wildcard, then scope. Distinguish event mismatch, scope mismatch, duplicate suppression, and the 5-second debounce merge. Paused or cancelled rules must not create a new normal dispatch.\n\nNext inspect queued/delivered/skipped/failed state, target availability, permission, rate limit, chain-depth guard, and result recording. Fire events are retained for 90 days. An offline target has a 300-second grace; stale in-flight work is reclaimed after 75 minutes, stuck firing after 5 minutes, and an unrecorded delivered task receives timeout notification after 3,660 seconds. `record_run_result` is runtime bookkeeping. Never place full event payload or `systemMessage` in routing telemetry.\n",
  "aliases": [
    "trigger fire event",
    "event did not match",
    "scope mismatch",
    "debounced event",
    "delivery failed",
    "trigger timeout"
  ],
  "tags": [
    "trigger",
    "debugging",
    "fire-event"
  ],
  "relatedActions": [
    "arinova.trigger.get_trigger",
    "arinova.trigger.record_run_result"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/trigger/fire-events-and-debugging/"
}
---

Separate four stages: the resource event matched, dispatch entered the queue, the Agent executed the task, and a result was recorded. `get_trigger` exposes the rule, replacement lineage, fire count, and last-fire summary; fire-event query surfaces provide recent execution detail. A successful create or match is not proof of successful Agent execution.

Canonical run-result statuses are `success`, `partial`, `failed`, `skipped`, `timeout`, and `unknown`. For a no-fire report, check active/paused/cancelled state, source type, event type or wildcard, then scope. Distinguish event mismatch, scope mismatch, duplicate suppression, and the 5-second debounce merge. Paused or cancelled rules must not create a new normal dispatch.

Next inspect queued/delivered/skipped/failed state, target availability, permission, rate limit, chain-depth guard, and result recording. Fire events are retained for 90 days. An offline target has a 300-second grace; stale in-flight work is reclaimed after 75 minutes, stuck firing after 5 minutes, and an unrecorded delivered task receives timeout notification after 3,660 seconds. `record_run_result` is runtime bookkeeping. Never place full event payload or `systemMessage` in routing telemetry.