Executions

Understand how TrigRun runs your jobs, handles retries, and stores execution results.

An execution is one logical run of a job. Each execution tracks the scheduled time, delivery attempts, and final outcome.

Execution lifecycle

Job schedule fires
    ↓
Execution created (status: queued)
    ↓
Worker picks up execution (status: running)
    ↓
HTTP request made to target URL
    ↓
┌─── Success (configured success_statuses and any response_matcher rules)
│        → status: succeeded
│
└─── Failure (timeout, connection error, non-success status, or response body mismatch)
         → Retry with exponential backoff
         → After max_attempts exhausted → status: failed

Execution statuses

Status	Meaning
`queued`	Waiting to be picked up
`running`	HTTP request in flight
`waiting`	Parked execution waiting on a webhook callback or approval
`succeeded`	Target satisfied `success_statuses` and any configured response matcher
`failed`	All attempts exhausted without success

Retry behavior

When an attempt fails, TrigRun retries based on the job's retry policy:

Backoff: 250ms * 2^attempt (exponential with jitter)
Default max_attempts: 3 (including the first attempt)
Default retry_on_statuses: 429, 500, 502, 503, 504
Timeouts and connection errors always trigger a retry
Response body failures do not create a new retry path on their own

Workflow jobs track step-level retries and parked waiting states separately from the top-level execution status.

You configure retry behavior per job:

{
  "retry_policy": {
    "max_attempts": 5,
    "retry_on_statuses": [429, 500, 502, 503, 504]
  }
}

Attempts

Each attempt within an execution records:

Field	Description
`number`	Attempt number (1, 2, 3...)
`status`	`SUCCESS`, `TIMEOUT`, `CONNECTION_ERROR`, `HTTP_ERROR`
`statusCode`	HTTP status code (if the request completed)
`latencyMs`	Round-trip time in milliseconds
`bodyPreview`	Truncated response body (up to 64 KB)
`responseHeaders`	Selected response headers
`errorClass`	Error category for failed attempts

Workflow executions also include per-step execution records and, when configured, a final_output object derived from response_output_template.

Outbound headers and variables

TrigRun automatically adds this header to every outbound request:

Header	Value
`X-Cron-Service-Execution-Id`	The execution ID

If you want the execution ID, timestamp, or a generated request UUID in additional headers, URLs, or bodies, use the supported dynamic variables documented in Request Templates and Response Matching.

For workflow jobs, the detail view also shows trigger_input and any parked waiting payload so you can trace inbound webhook or approval flows end to end.

Viewing executions

All executions in the workspace:

curl "https://api.trigrun.com/v1/executions" \
  -H "Authorization: Bearer $TOKEN"

Executions for a specific job:

curl "https://api.trigrun.com/v1/jobs/JOB_ID/executions" \
  -H "Authorization: Bearer $TOKEN"

Filter and paginate:

curl "https://api.trigrun.com/v1/executions?status=failed&from=2026-03-01T00:00:00Z&sort=scheduled_for&order=desc&limit=10" \
  -H "Authorization: Bearer $TOKEN"

Query parameters:

Parameter	Type	Description
`status`	string	Filter: `queued`, `running`, `succeeded`, `failed`
`from`	datetime	Start of time range (ISO 8601)
`to`	datetime	End of time range (ISO 8601)
`job_name`	string	Search by job name (case-insensitive, partial match)
`sort`	string	Sort by: `scheduled_for` or `created_at`
`order`	string	`asc` or `desc` (default: `desc`)
`limit`	integer	Max results, 1–100 (default: 50)
`offset`	integer	Skip N results for pagination

The same filters are available on /v1/jobs/:id/executions.

Execution details

Get a single execution with all attempts:

curl "https://api.trigrun.com/v1/executions/EXECUTION_ID" \
  -H "Authorization: Bearer $TOKEN"

{
  "id": "clx...",
  "job_id": "clx...",
  "job_name": "health-check",
  "status": "succeeded",
  "scheduled_for": "2026-03-15T10:00:00.000Z",
  "source": "schedule",
  "attempts": [
    {
      "number": 1,
      "status": "HTTP_ERROR",
      "statusCode": 503,
      "latencyMs": 89
    },
    {
      "number": 2,
      "status": "SUCCESS",
      "statusCode": 200,
      "latencyMs": 142,
      "bodyPreview": "{\"ok\":true}"
    }
  ],
  "final_response": {
    "statusCode": 200,
    "bodyPreview": "{\"ok\":true}"
  }
}

Replaying an execution

Re-run a failed (or any) execution:

curl -X POST "https://api.trigrun.com/v1/executions/EXECUTION_ID/replay" \
  -H "Authorization: Bearer $TOKEN"

This creates a new execution with source: "replay", scheduled for now. The original execution is unchanged.

Execution sources

Source	Meaning
`schedule`	Triggered by the job's schedule
`manual`	Triggered by "run now"
`replay`	Triggered by replaying a previous execution
`webhook`	Triggered by a public inbound webhook

CLI reference

trigrun executions list                      # All executions
trigrun executions list --job JOB_ID         # For a specific job
trigrun executions get EXECUTION_ID          # Execution details
trigrun executions replay EXECUTION_ID       # Replay

On this page