Automations

Destinations

Where automation results get delivered. Email, Slack, and webhook destinations, each with an always or smart delivery mode.

A destination is where an automation's result gets delivered when a run finishes. An automation can have any number of destinations, and each one carries its own delivery mode.

Modes

  • always: deliver on every completed run.
  • smart: deliver only when the agent judged the run noteworthy. Skipped deliveries are recorded with the reason not_noteworthy.

Destinations default to smart when no mode is set. Failed runs are the exception: a failure is delivered to every destination regardless of mode, so a smart destination never hides a broken automation.

Email

Sends to a fixed list of addresses.

Email destination
{ "type": "email", "name": "Platform team", "emails": ["oncall@acme.dev", "sre@acme.dev"], "mode": "smart" }

Completed runs arrive with the subject Automation completed: <name>. The body carries the agent's summary, the workspace name, the trigger time, the run duration, and a link to the execution in the console. Failures use the subject Automation stopped early: <name>, and the body carries the error instead of the summary and omits the duration.

Slack

Posts to a channel through your connected Slack integration.

Slack destination
{ "type": "slack", "name": "Alerts channel", "channelId": "C0812AB34", "mode": "always" }

channelId is the Slack channel identifier. If your workspace has more than one Slack integration connected, set integrationId to pick one; otherwise the first active integration is used. The message shows a headline with the automation name and outcome, the agent's summary, the trigger time, the duration for completed runs, and the workspace, plus a View execution button that opens the run in the console. If no active Slack integration exists, the delivery is recorded as failed with slack_not_connected.

Webhook

Sends an HTTP POST with a JSON body to any URL you control. Use it to chain runs into your own tools, issue trackers, or paging systems.

Webhook destination
{
  "type": "webhook",
  "name": "Internal pager",
  "url": "https://hooks.acme.dev/polylane",
  "headers": { "Authorization": "Bearer <token>" },
  "mode": "always"
}

Custom headers are merged into the request, so you can carry an authentication token. The request times out after 10 seconds, and any non-2xx response records the delivery as failed.

The payload for a completed run:

Webhook payload
{
  "event": "automation.executed",
  "automation": { "id": "auto_9f2c", "name": "Triage checkout alerts" },
  "execution": {
    "id": "exec_51ab",
    "summary": "Latency spike on checkout-api traced to the 14:02 deploy; opened an issue with the findings.",
    "triggeredAt": "2026-07-14T14:05:12.000Z",
    "completedAt": "2026-07-14T14:07:44.000Z",
    "durationMs": 152000,
    "noteworthy": true
  },
  "workspace": { "id": "ws_3d81", "name": "Acme" },
  "timestamp": "2026-07-14T14:07:45.000Z"
}

On failure, event is automation.failed and the execution object carries an error message instead of summary, completedAt, and durationMs.

Delivery tracking

Every delivery attempt is recorded against the execution with a sent or failed status and the recipient it targeted, so you can audit from the execution page which destinations received the result. Destinations only cover run results; for workspace-level alerts about the platform itself, see Notifications.