Skip to content

Post-Actions

Post-actions are reusable HTTP callbacks that fire automatically after a webhook or schedule run completes. They let you notify external systems (Slack, PagerDuty, custom APIs) about execution results without writing any integration code.

Use Cases

  • Slack notifications: Send a message to a channel when a scheduled task finishes or fails.
  • Incident management: Create a PagerDuty or Opsgenie incident when an agent run fails.
  • Webhooks to external systems: Forward execution results to your own API for logging, metrics, or further processing.
  • Status dashboards: Push run results to a status page or monitoring tool.

How Post-Actions Work

  1. Create a post-action: Define a reusable HTTP request template (method, URL, headers, body, auth).
  2. Bind it: Attach the post-action to one or more webhooks or schedules via bindings. Each binding specifies when to fire: on success, failure, or any outcome.
  3. Automatic execution: When a webhook or schedule run completes, all matching bindings are evaluated and their post-actions are fired in parallel.
  4. Fire-and-forget: Post-actions never block the webhook or schedule. They run asynchronously in the background.

Key Concepts

Post-Action

A post-action is a reusable HTTP request definition. It includes:

  • Method: GET, POST, PUT, PATCH, or DELETE.
  • URL: The endpoint to call. Supports template variables.
  • Headers: Custom HTTP headers (e.g., Content-Type: application/json).
  • Body template: The request body with template variables that are replaced at execution time.
  • Authentication: Optional auth (Bearer token, Basic auth, or custom header).
  • Timeout: Per-request timeout (1-300 seconds, default 30).
  • Retry count: Number of retry attempts on failure (0-5, default 0).

Binding

A binding connects a post-action to a specific webhook or schedule. It specifies:

  • Trigger type: webhook or schedule.
  • Trigger: Which specific webhook or schedule to watch.
  • Fire when: any (always fire), success (only on success), or failure (only on failure/timeout).
  • Body override: Optionally override the post-action's default body template for this specific binding.
  • Enabled: Toggle the binding on or off without deleting it.

A single post-action can have multiple bindings, allowing you to reuse the same notification template across different webhooks and schedules.

Run History

Every post-action execution is recorded. For each run you can see:

  • Status: success or failed.
  • HTTP status code: The response code from the target server.
  • Request sent: The method and URL that was called.
  • Response body: The first 4KB of the response.
  • Error: Error details if the request failed.
  • Duration: How long the request took.

Template Variables

Use double-brace placeholders in the URL, body template, or header values. These are replaced with actual values at execution time:

Variable Description
{{status}}Run result: success or failed
{{trigger_type}}Source type: webhook or schedule
{{trigger_name}}Name of the webhook or schedule that triggered the run
{{team_name}}Name of the agent team
{{run_id}}Unique identifier of the source run
{{response}}The agent's response text (JSON-escaped in JSON templates)
{{error}}Error message if the run failed (empty on success)
{{prompt}}The prompt that was sent to the agent
{{started_at}}Run start timestamp
{{finished_at}}Run end timestamp

When the template looks like JSON (starts with { or [), variable values are automatically JSON-escaped to prevent broken payloads.

Example: Slack Notification

To send a Slack message when a schedule completes:

  1. Create a post-action with:
    • Method: POST
    • URL: Your Slack incoming webhook URL
    • Header: Content-Type: application/json
    • Body template: 
      {
  "text": "{{trigger_type}} '{{trigger_name}}' finished: {{status}}\nTeam: {{team_name}}\nRun: {{run_id}}\nError: {{error}}"
}
  2. Create a binding to your schedule with Fire when: any.
  3. The next time the schedule runs, you will get a Slack message with the result.

Authentication

Post-actions support four authentication modes:

Mode Description
NoneNo authentication. Suitable for services that use URL-based auth (e.g., Slack webhooks).
BearerAdds an Authorization: Bearer <token> header.
BasicAdds HTTP Basic Authentication with username and password.
Custom HeaderAdds a custom header with a name and value you specify (e.g., X-API-Key).

Authentication credentials are encrypted at rest using AES-256-GCM.

Retry Behavior

When a post-action fails (network error or HTTP 5xx response), it retries with exponential backoff:

  • 1st retry after 1 second
  • 2nd retry after 2 seconds
  • 3rd retry after 4 seconds
  • Up to a maximum of 5 retries, capped at 30 seconds between attempts

HTTP 4xx responses are not retried (they indicate a client error that won't resolve with retrying).

Managing Post-Actions

From the Post-Actions Page

Navigate to Post-Actions in the sidebar to see all defined post-actions. From here you can create, edit, enable/disable, or delete post-actions and view their run history.

From Webhook/Schedule Detail Pages

Each webhook and schedule detail page has a Post-Action Bindings section where you can add, edit, or remove bindings directly. This lets you manage which post-actions fire for a specific trigger without leaving the page.

Architecture Notes

  • Post-actions are fire-and-forget: they never block or delay the webhook/schedule response.
  • Multiple bindings for the same trigger execute in parallel.
  • Post-actions are not tied to teams: they are a platform-level feature.
  • There are no SSRF restrictions: post-actions can reach private IPs and internal services. This is by design, as AgentCrew is typically deployed behind a VPN or in a private network.

Next Steps

  • Webhooks: Learn about webhook triggers that can fire post-actions.
  • Schedules: Learn about scheduled tasks that can fire post-actions.
  • Configuration: Review all environment variables.