Labor0 Docs

Rescue CI

Rescue CI collects required GitHub Actions workflow results for one project-bound repository and creates reviewable repair-planning work when a required workflow fails or times out.

Installing Rescue CI, collecting and evaluating workflow results, and sending notifications do not add a Labor0 usage charge. Accepted planning work follows the ordinary task usage and pricing terms; see Pricing and usage.

Before you begin

You need a project-bound repository, an active GitHub event automation connection, a failure-notification UserGroup with at least one current member authorized to operate the exact project, the repository’s current default branch, and at least one active GitHub Ruleset required workflow. Every required workflow definition must be accessible through the selected connection and belong to the primary repository’s organization; cross-organization or inaccessible definitions are rejected during preview. If the project and repository already have GitHub event automation, use the exact connection that established that automation target. Trimmed installation names must be unique across the entire project, including installations of other templates. Preview does not check name availability, so installation can still be rejected after a successful workflow preview; rename the installation or remove the conflicting installation. Only one non-uninstalled Rescue CI installation is allowed for an exact project and repository. A Workspace Operator or equivalent project-configuration permission is required to install or change Rescue CI. Workspace Viewers can inspect Rescue CI runtime, Rescue episodes, and their results.

The optional Prompt template may use only the bounded fields shown in the form. A privacy-safe example is:

Review {{ .repository.fullName }} on {{ .repository.defaultBranch }}.{{ range .failedJobs }} Failed job: {{ .name }}.{{ end }} Propose the smallest repair plan.

Do not embed logs, workflow input, credentials, provider payloads, or issue content in the custom template or bounded handoff metadata. The resulting planning work may inspect the original failed runs and their Actions logs as evidence through its authorized GitHub access. Every output path must end with a non-whitespace character; remove trailing spaces or newlines. If the form exposes a different supported field spelling, use the field shown there.

Install Rescue CI

  1. Open the project’s Automation page.
  2. Select Add template, then choose Rescue CI.
  3. Complete Installation details, including the name and failure-notification UserGroup.
  4. Complete GitHub source with the project-bound repository and active GitHub event automation connection.
  5. Optionally complete Prompt template with a bounded template.
  6. Optionally expand Optional runtime settings. Runtime, Model, Reasoning effort, Runner selection, Plan mode, Fast mode, and Graph-change auto-approval use the Project default unless you select an override. An explicit Model is trimmed and must not be blank.
  7. Select Preview required workflows. Check Default branch and Required workflows. Confirm that at least one active, accessible Ruleset-required workflow from the primary repository’s organization is listed. Runtime settings do not affect this preview.
  8. Select Install template.
  9. Wait for the installation to become Active, then confirm Rescue CI runtime and Rescue episodes are available for the installation.

How Rescue CI works

Rescue CI considers completed GitHub Actions runs from pushes to the repository’s current default branch after the installation becomes active. Runs completed before installation are not backfilled. To confirm that Rescue CI is working, wait for a later eligible push and its required workflows to finish; it then creates repair-planning work only when at least one required workflow failed or timed out, including failures that do not require code changes. Open planning task appears only after that exact episode has a planning task. Each commit can produce at most one Rescue handoff for this installation. Reruns of required workflows for the same commit converge on the existing episode instead of creating another planning task; another handoff requires a new eligible push. An episode snapshots its effective runtime and Graph-approval submission options before its first planning handoff, so retries keep those options after later installation edits; the next independent episode uses the newly saved configuration. Runtime-only detail edits save immediately without a provider preview, while mixed runtime and prompt/source edits wait for a current preview of the preview-relevant values and then save atomically.

Customer-impacting limits are 24 hours per collection, 50 required workflows, 100 failed or timed-out jobs, and 10 handoffs per rolling hour. Rescue CI does not rerun Actions automatically, write code, create branches or pull requests, or infer downstream task, pull-request, or merge completion. After the normal planning workflow, accepted reviewed work may rerun only failed jobs when evidence indicates a flaky or infrastructure failure; deterministic repository-owned failures are handled through code changes and the normal review and approval process.

Expected result

The installation is visible in Rescue CI runtime, and collected attempts appear under Rescue episodes. A completed default-branch collection with a failed or timed-out required workflow shows its repair-planning outcome. Open planning task is available only when the exact episode has received a planning task; an episode that is still collecting or has no qualifying failure does not show that action. Rescue episodes are retained for 90 days, so preserve any needed evidence before they expire.

Permissions and lifecycle

Workspace Viewers can inspect runtime status and episodes. Workspace Operators can install, update, pause, resume, retry, and uninstall Rescue CI. The selected failure-notification UserGroup receives supported project notifications and is also the planning audience: its eligible members receive interactive planning questions and review-ready notifications. Selecting the group does not grant project access.

Recover safely

  • GitHub needs reconnecting during setup: reconnect the active GitHub event automation connection and run Preview required workflows again. Wait for a transient provider or rate-limit condition rather than creating a duplicate installation.
  • No required workflows, an inaccessible workflow source, or a malformed Ruleset workflow during setup: update the repository Ruleset so at least one active required workflow is valid, accessible through the selected connection, and sourced from the primary repository’s organization, then run Preview required workflows again. Install only after the preview lists usable required workflows.
  • Installation fails because the notification group is not eligible: make sure the selected same-tenant UserGroup contains at least one current member authorized to operate the exact project, then retry the installation or its failed operation. Preview can succeed before this membership check is applied.
  • Collection deadline exceeded: inspect the incomplete Ruleset runs and wait for the required workflows to reach a terminal state before using Pause and Resume on the installation. After resuming, push a new eligible commit to start a new collection; the timed-out episode is not recreated.
  • More than 50 required workflows: reduce the repository Ruleset’s required workflow set, then use Pause and Resume on the installation. The paused collection is not recreated; push a new eligible commit to start a new collection.
  • More than 100 failed or timed-out jobs: reduce the failed-job set, then use Pause and Resume on the installation. The paused collection is not recreated; push a new eligible commit to start a new collection.
  • A Rescue installation already exists for this project and repository: use the existing configured installation, or uninstall it before creating a replacement.
  • Ruleset data is inaccessible, malformed, or exceeds the workflow limit after installation: a failed or timed-out delivery auto-pauses Rescue CI. Correct the repository Ruleset, then select Pause followed by Resume on the installation. The failed episode is not recreated, so push a new eligible commit to start a new collection.
  • Ruleset changes after installation: when an authoritative observation shows zero active required workflows, Rescue CI remains active but idle. Restore at least one active required workflow; do not run setup preview for the installed runtime.
  • The provider remains unavailable after installation: wait for provider recovery, then select Pause followed by Resume on the installed Rescue runtime. Push a new eligible commit to start a new collection and create planning work; the failed episode for the original commit is not recreated.
  • GitHub access is lost after installation: reconnect the active GitHub event automation connection, then use Pause followed by Resume on the installed Rescue runtime. After resuming, push a new eligible commit to start a new collection and create planning work; the failed episode for the commit that lost authorization is not recreated.
  • Prompt rendering or validation fails during setup: use only the bounded fields and supported syntax shown by Prompt template, remove logs and payloads, and run Preview required workflows again. Do not use an unrestricted fallback prompt.
  • An installed Rescue runtime auto-pauses because its prompt cannot render: edit the prompt using only the bounded fields and supported syntax, select Preview changes, then select Save changes to persist the corrected prompt. After the saved correction, select Pause followed by Resume on the installation to reactivate Rescue CI. Do not resume the runtime with the old failing template.
  • Submission failure: the Rescue runtime pauses after submission retries are exhausted. Restore task submission, then select Pause followed by Resume on the installation. After resuming, push a new eligible commit to start a new collection and create planning work; the failed episode is not recreated, and the episode view does not offer a submission Retry action. Rescue CI does not rerun Actions automatically.
  • Handoff rate limit: the eleventh handoff in a rolling hour automatically pauses the Rescue runtime. Wait for the rolling window to clear, then use Pause and Resume on the installation. The failed episode is not recreated, so push a new eligible commit to start a new collection; this limit does not create an episode Retry operation.
  • Authorization or billing block: ask a Workspace Operator or administrator to restore the required permission or billing readiness, then retry the named operation.
  • Pause, resume, or uninstall: Pause stops new collection work and leaves any episode that is still collecting or whose handoff has not been issued abandoned; deliveries received while the runtime is inactive are discarded. Resume does not continue or recreate that interrupted installation/commit episode, so push a new eligible commit after resuming when you still need Rescue work for that failure. Use Retry for a failed operation and Uninstall only when the installation is no longer needed; accepted planning work remains available through its normal project workflow.