Retries, timeouts & conditions

These options live in each step’s Flow section. They apply to every step type unless noted.

Retries on failure

UI label	JSON	Default	Range (UI)
Retries on failure	retries	0	0–10

retries is the number of extra attempts after a failure: 0 runs the step once, 1 allows one retry, and so on.

• Between attempts Jimothy waits with exponential backoff: 2s, 4s, 8s, 16s, then 30s for every further retry. Cancelling the run interrupts the wait.
• Each attempt gets its own log (Retry 1/2 is logged at the start) and is listed on the step’s Details tab.
• Cost and tokens from every attempt are added to the step and run totals.
• Not retried: verdict failures (pass/fail pattern), cancellations, and approval steps (an approval runs once per pass).
• The step’s output and error are those of the last attempt.

Retries fit transient failures: rate limits, network hiccups, a flaky agent session. Long coding steps in the built-in templates use retries: 1. For deterministic failures such as failing tests, use a feedback loop instead, which re-runs the step that can fix the problem.

Tip

Try retries with the Simulator: its flaky model fails the first attempt (“Simulated transient failure”) and succeeds on the second.

Timeout

UI label	JSON	Default
Timeout (minutes)	timeoutMinutes	none

When an attempt runs longer than the timeout:

• CLI and shell steps: the whole process tree gets SIGTERM, then SIGKILL 5 seconds later. The attempt fails with Timed out after N min.
• API harness steps: the call is abandoned and fails with Timed out after N min.

A timeout is a normal failure, so it’s retried if Retries on failure allows it, and triggers the loop-back if one is set. Empty or 0 means no timeout. Approval steps ignore it and wait indefinitely.

Suggested values (from the pipeline-builder skill): coding agents 20–60 minutes, triage or small reviews 5–15, shell steps 5–20.

Run only if (runIf)

UI label	JSON	Default
Run only if	runIf	empty (always run)

A template evaluated when the step becomes ready (after its dependencies finish). If it renders to a falsy string, the step is Skipped with Condition not met: <template>. Otherwise the step runs.

A rendered value is falsy when, after trimming and lowercasing, it is:

• empty ('')
• false
• 0
• no

Anything else is truthy, including off, null and whitespace-padded text.

A step skipped by its condition does not block its dependents: they run normally, and {{steps.<id>.output}} is empty for the skipped step. (Compare steps skipped because an upstream step failed, which do propagate.)

Examples

Run a deploy step only when a per-run variable is set (the step’s placeholder in the UI):

{{vars.deploy}}

Start the run with vars.deploy = yes in the Start a run dialog to include it; leave it empty (or set false) to skip.

Run only when the issue has any labels:

{{#if issue.labels}}yes{{/if}}

Run only if an earlier step produced output:

{{steps.triage.output}}

Run only when an earlier step failed (useful together with Continue on error on that step, see below):

{{#if steps.test.error}}yes{{/if}}

Run only when a classifier step (for example an API-harness step prompted to answer exactly yes or no) said yes:

{{steps.needs_docs.output | trim | lower}}

Note

Templates can test whether a value is truthy, but can’t compare values (==, contains). Put the decision in an earlier step (an API-harness classifier or a shell command that prints yes/no) and reference its output in runIf.

Continue on error

UI label	JSON	Default
Continue the pipeline even if this step fails	continueOnError	off

When a step with this option fails (after retries and loops):

• The step is still shown as Failed, and step.failed still fires.
• Its dependents run anyway instead of being skipped.
• The run can still succeed: steps with Continue on error don’t count when deciding whether the run failed.

Use it for advisory or optional work: a non-blocking security scan, a lint pass whose findings the reviewer reads, posting a comment that might fail. Downstream steps can read {{steps.<id>.status}} (failed/succeeded) and {{steps.<id>.error}} to react.

{ "id": "audit", "name": "Dependency audit", "type": "shell", "dependsOn": ["implement"],
  "command": "npm audit --audit-level=high", "continueOnError": true }

{{#if steps.audit.error}}
npm audit reported problems (advisory, not blocking):
{{steps.audit.output | truncate:3000}}
{{/if}}

Order of evaluation

For each step, in order:

1. Upstream check: a failed/cancelled dependency without Continue on error skips the step.
2. Run only if: falsy skips the step.
3. Attempt 1 runs, with the timeout.
4. If it succeeded, verdict patterns are checked.
5. On a non-verdict failure, retries with backoff.
6. If it still failed, loop back if the budget allows.
7. Otherwise it’s Failed; Continue on error decides whether dependents run.