Executions & run history

Executions & run history

Every time a job runs, Cronable records an execution (a “run”) — its outcome, timing, output, and full log. The Executions view is where you browse that history, watch runs live, and act on them. It stays fast no matter how much history accumulates: the list paginates and logs are tailed, never loaded whole (see Operations & scaling).

The run list

Runs appear newest-first, each showing the job name, state, when it started, how long it took, the attempt number (for retried runs), and what triggered it. Active runs update live — a run started elsewhere, or a state change, streams in over the dashboard’s live connection without a refresh.

Filter the list with the two selectors at the top:

  • By job — show only one job’s runs.
  • By staterunning, waiting, succeeded, failed, timed out, cancelled, or skipped (or all). Filtering to failed is the quickest way to scan for problems.

Load more pages through older history a chunk at a time, so the list never pulls your entire run history into the browser.

Searching runs

The search box above the list does a free-text search across your run history — a fast way to find “the run that printed ECONNREFUSED” or every run of a job whose id you only half-remember.

  • What it searches — the run’s error message and its recent output (the masked log tail shown in the detail panel), plus the job id, job type, and trigger detail. It does not scan each run’s full on-disk log — only the bounded, already-stored fields — so search stays fast no matter how much history has accumulated.
  • Substring, case-insensitivetimeout matches Connection timeout anywhere in a field. A literal % or _ in your query is matched as itself, not as a wildcard.
  • Combines with the filters — search alongside the job/state selectors to narrow further (e.g. state = failed + search timeout), and Load more pages through the matches.

Search runs entirely on the daemon over its bounded run history, so no run output is shipped to the browser just to be searched, and the query is always masked-safe (it searches the same redacted text you see). Clear the box to return to the full list.

A run’s detail

Select a run to see everything about it:

  • State + metadata — trigger (and detail), attempt number, start time, duration, exit code, signal, and (for HTTP jobs) the response status.
  • Error — when a run failed before producing output, the error is shown up top.
  • Result — the run’s structured output, i.e. exactly what a chained child job receives as {{ $parent }} (see Expressions & data flow). For a claude job this is its final answer, not the whole stream-json transcript.
  • Log — the raw stdout/stderr stream. For an active run it streams live; it is secret-masked (resolved secret values are redacted before anything is written).

Both the Result and the Log can be expanded to a full-screen view and copied.

Re-running and cancelling

  • Retry — on a settled run, re-runs its job immediately as a fresh manual run (a new execution with an incremented attempt). Useful after fixing a transient failure or a job’s config.
  • Cancel — on an active run, stops it (the daemon terminates the whole process group).

Downloading the full log

The Log panel shows only the most recent output — for a very large log it tails the end so the page stays responsive. When you need the whole log (to grep it, attach it to a bug report, or archive it), use the Download button in the Log header. It downloads the complete on-disk log as cronable-<runId>.log.

Two things keep this safe and bounded:

  • It’s already masked. The file is secret-masked as it’s written, so the download contains no unmasked secret values.
  • It’s size-capped. Each run’s log file is capped on disk by CRONABLE_LOG_MAX_MB (default 100 MB — see Operations & scaling), so a download is always bounded, and the daemon streams the file rather than loading it into memory.

Retention

Run history is bounded so a long-lived install never fills the disk: run rows, their logs, and the audit trail are all subject to the retention and size caps in Operations & scaling. In-flight runs are never pruned.