Executions

An execution is a single run of a job. Executions are created by schedules or by manual triggers, and they progress through a defined lifecycle.

Execution Lifecycle

pending → claimed → running → success
                                → failure
                                → timeout
                                → cancelled
                                → blocked_by_policy
             no-overlap skip   → no_overlap

Status	Description
`pending`	Created and waiting for an executor to claim it.
`claimed`	An executor has claimed the execution and is preparing to run it.
`running`	The job is actively executing.
`success`	The job completed successfully.
`failure`	The job failed (HTTP status `>=400`, non-zero exit, exception, or policy violation).
`timeout`	The job exceeded its `timeout_sec` budget.
`cancelled`	The execution was manually cancelled before completion.
`no_overlap`	A scheduled run was skipped because the job already had an in-flight execution and `no_overlap` was enabled.
`blocked_by_policy`	The execution was blocked by the current job security policy before executor code ran.

When no_overlap is enabled, scheduled overlaps are recorded as no_overlap rows and the schedule advances. Manual triggers do not create a skip row; they return a conflict response while another run is pending, claimed, or running.

Timeouts and Recovery

Pending timeout: Scheduled executions stuck in pending for longer than pending_timeout_sec (default 300s) are marked as timed out.
Claimed timeout: If a claimed execution isn't started within 5 minutes, it's recovered and made available for re-claiming.
Running timeout: Running executions are marked as timed out only after the retry-aware budget, (retry_count + 1) * timeout_sec + retry_count * retry_delay_sec, plus a 60-second grace period.

Trigger Types

Type	Description
`schedule`	Created automatically by a schedule's cron expression.
`manual`	Triggered by a user via the UI, API, or CLI. Records the requesting user ID.

Execution Details

Each execution captures:

Job snapshot — a copy of the job configuration at execution time, so history remains accurate even if the job is later modified or deleted.
Requester snapshot — manual triggers record the requesting user at trigger time when available.
Status code — the HTTP response status code (for HTTP and health check jobs).
Result — output from the execution (response body, container stdout, error messages).
Duration — wall-clock time in milliseconds from start to completion.
Attempt number — which retry attempt this is (1 for the first run).

Sensitive job config fields are redacted in job_snapshot. Pending or claimed executions may not have a snapshot yet; detail views fall back to the current job when it still exists. Result bodies are capped for storage and display, so very large response bodies or stdout may be truncated.

Forgetting execution history deletes old completed rows only. Live pending, claimed, and running executions are preserved.

Cancelling Executions

You can cancel a pending execution before an executor claims it. Cancelled executions are not retried.