Debug a rule using run history

Every automation run is recorded. The Run History tab shows routine event-triggered runs — when they happened, what triggered them, which rule ran, which actions succeeded or failed, and where to open the related conversation. This is your first stop when a rule isn’t doing what you think it should.

For runs started manually or in bulk, use Manual Executions if that tab is available in your workspace.

Before you start

• A rule you suspect isn’t behaving correctly
• Admin permissions to view the rules page

Steps

1. Open Run History. Go to Settings → Automation Rules and switch to the Run History tab.

2. Filter the history. Use the filters to narrow the list to the runs you care about:

   
   Status — show successful, failed, or other run states
   Date range — focus on the window when the issue happened

3. Load older runs if needed. Run History shows the most recent results first. Click Load More to page through older executions until you find the event you’re investigating.

4. Read the run row. Each row shows the rule and trigger that ran, when it ran, and action chips that summarize what happened. Use these chips to quickly see which actions succeeded and which failed.

5. Check failure details. If a run or action failed, read the failure reason shown on the row or in the expanded details. This is usually the fastest way to spot a missing template, invalid configuration, webhook error, or other downstream issue.

6. Open the related conversation. Use the conversation link in the run row to cross-reference what happened in the conversation. If the run isn’t tied to a conversation, the conversation field shows a dash instead.

7. Use Manual Executions for manual or bulk runs. If you’re debugging a rule you ran manually, or a bulk execution, open Manual Executions and inspect that run there instead of using Run History.

Common debugging patterns

Rule isn’t firing at all

1. Filter Run History to the date range when the event should have happened.
2. If there are no entries for the expected rule or trigger, the trigger isn’t firing.
3. Confirm the rule is enabled.
4. Confirm the trigger type matches the event you expect. (Most-common: picking Conversation created when you wanted Message received.)
5. If the trigger is Message received, confirm the message’s direction matches your conditions (inbound vs. outbound).

Rule fires but conditions don’t match

1. Open a run where you expected the rule to act.
2. Check the rule and trigger details to confirm the run came from the event you expected.
3. Review the rule’s conditions. The most common gotcha is a custom field’s stored value (machine slug) differing from its display label — your condition is comparing against the wrong representation.

Action fails

1. Filter Run History to failed runs, then open the failed run.
2. Read the failure reason for the failed action chip.
3. For HTTP-based actions (webhooks, Slack), the error usually includes the status code or response from the receiver.
4. For Send Email Studio template failures, confirm the template ID still exists and that the language being requested has a translation.

Rule fires twice for the same event

1. Open recent runs and check timestamps. Are they truly duplicates (within milliseconds) or separate triggering events (e.g., a status change and an agent assignment that arrived together)?
2. Compare the trigger details on each row to see whether the same trigger fired twice or two different triggers fired close together.
3. If duplicates, set up throttling per-conversation to coalesce them.

Webhook recipient not seeing payloads

1. Filter Run History to failed runs in the date range when the webhook should have fired.
2. If the webhook action shows success, Atender’s side completed the action.
3. If the webhook action failed, read the failure reason for the status code or receiver response.
4. A successful request with unexpected behavior usually means the receiver’s endpoint matched but the payload format or downstream handling is wrong.

Notes

• Execution history is retained for a limited window (the exact retention is in Settings — Conversation Resolution and your tenant’s data retention policy).
• Throttled executions are logged with status “throttled” and the reason (which throttle scope blocked them).
• Failed actions don’t stop the run — Atender continues to the next action in the branch and records the failure. If you need a rule to bail on first failure, use a webhook action with an explicit acknowledgment check downstream.
• Manual Executions is for runs started manually or in bulk. For routine event-triggered debugging, start with Run History.

See also

• Throttle a rule to prevent spam
• Simulate a rule before enabling
• Trigger types reference