---
title: "Loops"
description: "Scheduled and event-triggered loops that work assigned issues through a bounded run, inside the run policy's budgets, and stop when the policy is paused."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Loops

A **loop** works assigned issues for you on a schedule or when something happens. Each firing is an ordinary bounded run, the same kind the run commands start, so the run policy's limits apply.

```sh
overlane loop new Nightly --every 1440 --filter priority=P0
overlane loop new OnAssign --on issue.assigned
overlane loop list
overlane loop fire lop_ab12cd34ef56gh78
overlane loop update lop_ab12cd34ef56gh78 --enabled off
overlane loop archive lop_ab12cd34ef56gh78
overlane loop restore lop_ab12cd34ef56gh78
```

An archived loop never fires. Deleting a loop archives it first, so it can be restored for 30 days. See [Archive, restore and delete](/archive-and-delete/).

## Triggers

| Trigger | Fires |
| --- | --- |
| `--every MINUTES` | on a schedule, once per interval (5 minutes to 7 days) |
| `--on issue.created` | when an issue is created |
| `--on issue.assigned` | when an issue is assigned |
| `--on issue.updated` | when an issue changes |
| `--on sync.received` | when a GitHub delivery was applied |

## What a firing does

1. It starts a run. If the project's run policy is **paused**, the run is refused and the loop stops with reason `paused`.
2. It picks the issues assigned to the loop's agent that match the loop's filter and have a ready or paused task. The filter is the same field filter as a saved view.
3. It claims their tasks in queue order (priority, then rank) under the run, up to the run's task budget. When the budget is spent it stops with `budget_tasks`.
4. If it claimed nothing, it ends the run. Otherwise the run stays open for the agent to work through the claimed tasks and end.

A repeated firing finds those tasks already running and claims nothing more.

## No inference

Loops use no model. The filter, the order and the budgets are fixed rules. Nothing in an issue's text can change what a loop does.

## Roles

An agent defines, changes and deletes loops, and members can too through their role. Defining a loop is the issue triage autonomy class: nothing waits under `autonomous`, an approval is needed under `supervised`, and a person under `manual`. A loop's filter, order and budgets are fixed rules, so a loop cannot widen its own reach. Anyone who can write can fire a loop that exists; viewers cannot.

## Commands

[`overlane loop new`](/cli/loop-new/), [`loop list`](/cli/loop-list/), [`loop fire`](/cli/loop-fire/), [`loop update`](/cli/loop-update/), [`loop delete`](/cli/loop-delete/). Run limits are described with the run commands, for example [`overlane run start`](/cli/run-start/).

Source: https://docs.overlane.app/issues/loops/index.mdx
