Test deliveries and run history

The Automation detail page combines an incoming-webhook test tool with Run history. Use both: the form’s Accepted state means the durable request exists, while Run history and the destination prove completion.

Before you begin

Open an Automation you can manage. For an incoming-webhook test, prepare one representative JSON object that contains no live secret or customer data. If the action reaches an external system, make sure you can inspect its approved test destination.

Send a test delivery

1. Keep a new incoming-webhook Automation disabled.
2. Under Test delivery, enter one valid JSON object.
3. Select Start test delivery.
4. Confirm the inline state becomes Accepted.
5. Watch Run history for the corresponding Webhook delivery and Agent message rows.
6. Inspect the external destination.

Test deliveries use the same durable webhook and worker path as signed external requests. Agent messages are prefixed with [Test delivery]. Repeated submission of unchanged JSON is idempotent.

This real run-history crop security-masks Slack identifiers. Read source acceptance and external action as two stages of the same event.

Lifecycle states

State	Meaning	Operator action
Accepted	Request is validated and persisted.	Wait for processing.
Processing	The worker owns a renewable processing lease.	Wait unless the state is stale.
Generated	Agent output is persisted; Slack is not yet claimed.	Normally wait.
Posting	The external post has been claimed.	Do not start a duplicate.
Success / Succeeded	The action or delivery completed.	Validate the destination.
Failed before post	No Slack post was claimed.	Resolve the cause, then use Retry agent message where offered.
Failed after claim	Slack may have accepted the post before an ambiguous failure.	Inspect Slack before taking further action.

Product-event actions also use Pending, Running, Success, Failed, or Skipped. Skipped means at least one Condition did not match; it is not an external-delivery failure.

Run history columns

• Type distinguishes the webhook delivery from its action.
• Status is the durable lifecycle.
• Time anchors the event during external investigation.
• Error category gives a stable failure class without exposing secrets.
• External result identifies the Slack channel and message timestamp when recorded.
• Next step surfaces safety guidance, especially after a posting claim.

Success check

For one logical event, Run history contains one successful webhook delivery and one successful action. Slack contains one correctly framed message. Retrying the identical request with the same idempotency key does not add another message.

Troubleshooting

• If no run appears for a product event, confirm the Automation is enabled and that the expected supported trigger reached the same organization. A Condition mismatch appears as a Skipped run instead of hiding the run.
• If only a Webhook delivery appears, inspect whether the Automation or endpoint was disabled after acceptance.
• If a row is Failed, use its error category and current action configuration; do not infer the cause from the original definition alone.
• Never retry Failed after claim until the external destination has been checked for a completed side effect.

Related pages

• Incoming webhook trigger
• Agent message action
• Troubleshoot automations