> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cron

# `openclaw cron`

Керуйте завданнями Cron для планувальника Gateway.

<Tip>
  Запустіть `openclaw cron --help`, щоб побачити всю поверхню команд. Див. [Завдання Cron](/uk/automation/cron-jobs) для концептуального посібника.
</Tip>

## Швидке створення завдань

`openclaw cron create` є псевдонімом для `openclaw cron add`. Для нових завдань спочатку вказуйте розклад, а потім prompt:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron create "0 7 * * *" \
  "Summarize overnight updates." \
  --name "Morning brief" \
  --agent ops
```

Використовуйте `--webhook <url>`, коли завдання має надіслати завершене корисне навантаження через POST замість доставки в ціль чату:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron create "0 18 * * 1-5" \
  "Summarize today's deploys as JSON." \
  --name "Deploy digest" \
  --webhook "https://example.invalid/openclaw/cron"
```

Використовуйте `--command` для детермінованих завдань у стилі shell, які мають виконуватися всередині OpenClaw cron без запуску ізольованого виконання агента/моделі:

<Note>
  Командні завдання Cron — це створена адміністратором автоматизація Gateway. Для їх створення, редагування,
  видалення або ручного запуску потрібен `operator.admin`; запланований запуск
  пізніше виконується в процесі Gateway, а не як виклик інструмента агента `tools.exec`.
  `tools.exec.*` і підтвердження exec і надалі керують exec-інструментами, видимими для моделі.
</Note>

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron create "*/15 * * * *" \
  --name "Queue depth probe" \
  --command "scripts/check-queue.sh" \
  --command-cwd "/srv/app" \
  --announce \
  --channel telegram \
  --to "-1001234567890"
```

`--command <shell>` зберігає `argv: ["sh", "-lc", <shell>]`. Використовуйте `--command-argv '["node","scripts/report.mjs"]'` для точного виконання argv. Командні завдання захоплюють stdout/stderr, записують звичайну історію Cron і маршрутизують вивід через ті самі режими доставки `announce`, `webhook` або `none`, що й ізольовані завдання. Команда, яка виводить лише `NO_REPLY`, пригнічується.

## Сеанси

`--session` приймає `main`, `isolated`, `current` або `session:<id>`.

<AccordionGroup>
  <Accordion title="Ключі сеансів">
    * `main` прив’язується до основного сеансу агента.
    * `isolated` створює нову стенограму та ідентифікатор сеансу для кожного запуску.
    * `current` прив’язується до активного сеансу на момент створення.
    * `session:<id>` закріплюється за явним постійним ключем сеансу.
  </Accordion>

  <Accordion title="Семантика ізольованих сеансів">
    Ізольовані запуски скидають навколишній контекст розмови. Маршрутизація каналів і груп, політика надсилання/черги, підвищення прав, походження та прив’язка середовища виконання ACP скидаються для нового запуску. Безпечні налаштування та явні вибрані користувачем перевизначення моделі або автентифікації можуть переноситися між запусками.
  </Accordion>
</AccordionGroup>

## Доставка

`openclaw cron list` і `openclaw cron show <job-id>` попередньо показують розв’язаний маршрут доставки. Для `channel: "last"` попередній перегляд показує, чи маршрут розв’язано з основного або поточного сеансу, чи він завершиться закритою відмовою.

Цілі з префіксом провайдера можуть усувати неоднозначність нерозв’язаних каналів оголошень. Наприклад, `to: "telegram:123"` вибирає Telegram, коли `delivery.channel` пропущено або має значення `last`. Лише префікси, оголошені завантаженим Plugin, є селекторами провайдера. Якщо `delivery.channel` задано явно, префікс має відповідати цьому каналу; `channel: "whatsapp"` з `to: "telegram:123"` відхиляється. Сервісні префікси, такі як `imessage:` і `sms:`, залишаються синтаксисом цілі, що належить каналу.

<Note>
  Ізольовані завдання `cron add` за замовчуванням використовують доставку `--announce`. Використовуйте `--no-deliver`, щоб залишити вивід внутрішнім. `--deliver` залишається застарілим псевдонімом для `--announce`.
</Note>

### Власність доставки

Доставка ізольованого Cron у чат розподілена між агентом і runner:

* Агент може надсилати напряму за допомогою інструмента `message`, коли доступний маршрут чату.
* `announce` доставляє фінальну відповідь як fallback лише тоді, коли агент не надіслав її напряму до розв’язаної цілі.
* `webhook` надсилає завершене корисне навантаження на URL.
* `none` вимикає fallback-доставку runner.

Використовуйте `cron add|create --webhook <url>` або `cron edit <job-id> --webhook <url>`, щоб налаштувати доставку через webhook. Не поєднуйте `--webhook` із прапорцями доставки в чат, такими як `--announce`, `--no-deliver`, `--channel`, `--to`, `--thread-id` або `--account`.

`cron edit <job-id>` може прибрати окремі поля маршрутизації доставки за допомогою `--clear-channel`, `--clear-to`, `--clear-thread-id` і `--clear-account` (кожен із них відхиляється, якщо поєднаний із відповідним прапорцем установлення). На відміну від `--no-deliver`, який лише вимикає fallback-доставку runner, ці параметри видаляють збережене поле, щоб завдання знову розв’язувало цю частину маршруту зі значень за замовчуванням.

`--announce` — це fallback-доставка runner для фінальної відповіді. `--no-deliver` вимикає цей fallback, але не видаляє інструмент агента `message`, коли доступний маршрут чату.

Нагадування, створені з активного чату, зберігають поточну ціль доставки чату для fallback-доставки оголошення. Внутрішні ключі сеансів можуть бути в нижньому регістрі; не використовуйте їх як джерело істини для чутливих до регістру ідентифікаторів провайдерів, таких як ідентифікатори кімнат Matrix.

### Доставка збоїв

Сповіщення про збої розв’язуються в такому порядку:

1. `delivery.failureDestination` у завданні.
2. Глобальне `cron.failureDestination`.
3. Основна ціль оголошення завдання (коли явну ціль для збоїв не встановлено).

<Note>
  Завдання основного сеансу можуть використовувати `delivery.failureDestination` лише тоді, коли основний режим доставки — `webhook`. Ізольовані завдання приймають його в усіх режимах.
</Note>

Примітка: ізольовані запуски Cron трактують збої агента на рівні запуску як помилки завдання навіть тоді, коли
корисне навантаження відповіді не створено, тому збої моделі/провайдера все одно збільшують лічильники помилок
і запускають сповіщення про збої.

Командні завдання Cron не запускають ізольований хід агента. Нульовий код виходу записує
`ok`; ненульовий код виходу, сигнал, тайм-аут або тайм-аут без виводу записує `error` і
може запустити той самий шлях сповіщення про збій.

Якщо ізольований запуск завершується тайм-аутом до першого запиту моделі, `openclaw cron show`
і `openclaw cron runs` включають помилку, специфічну для фази, наприклад
`setup timed out before runner start` або
`stalled before first model call (last phase: context-engine)`.
Для провайдерів, що працюють через CLI, передмодельний watchdog залишається активним, доки не почнеться зовнішній
хід CLI, тому зависання пошуку сеансу, hook, автентифікації, prompt і налаштування CLI
повідомляються як передмодельні збої Cron.

## Планування

### Одноразові завдання

`--at <datetime>` планує одноразовий запуск. Дати й час без зміщення трактуються як UTC, якщо ви також не передали `--tz <iana>`, який інтерпретує локальний час у заданому часовому поясі.

<Note>
  Одноразові завдання за замовчуванням видаляються після успіху. Використовуйте `--keep-after-run`, щоб зберегти їх.
</Note>

### Повторювані завдання

Повторювані завдання використовують експоненційний backoff повторних спроб після послідовних помилок: 30s, 1m, 5m, 15m, 60m. Розклад повертається до нормального після наступного успішного запуску.

Пропущені запуски відстежуються окремо від помилок виконання. Вони не впливають на backoff повторних спроб, але `openclaw cron edit <job-id> --failure-alert-include-skipped` може ввімкнути для сповіщень про збої повторні повідомлення про пропущені запуски.

Для ізольованих завдань, які націлені на локально налаштованого провайдера моделі, Cron виконує легку попередню перевірку провайдера перед запуском ходу агента. Loopback, приватно-мережеві та `.local` провайдери `api: "ollama"` перевіряються за `/api/tags`; локальні OpenAI-сумісні провайдери, такі як vLLM, SGLang і LM Studio, перевіряються за `/models`. Якщо endpoint недоступний, запуск записується як `skipped` і повторюється за пізнішим розкладом; відповідні недіючі endpoints кешуються на 5 хвилин, щоб багато завдань не навантажували той самий локальний сервер.

Примітка: завдання Cron, очікуваний стан середовища виконання та історія запусків зберігаються у спільній базі даних стану SQLite. Застарілі файли `jobs.json`, `jobs-state.json` і `runs/*.jsonl` імпортуються один раз і перейменовуються з суфіксом `.migrated`. Після імпорту редагуйте розклади за допомогою `openclaw cron add|edit|remove`, а не редагуванням JSON-файлів.

### Ручні запуски

`openclaw cron run <job-id>` за замовчуванням виконує примусовий запуск і повертається щойно ручний запуск поставлено в чергу. Успішні відповіді містять `{ ok: true, enqueued: true, runId }`. Використовуйте повернений `runId`, щоб переглянути пізніший результат:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --run-id <run-id>
```

Додайте `--wait`, коли скрипт має блокуватися, доки саме цей поставлений у чергу запуск не запише термінальний статус:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron run <job-id> --wait --wait-timeout 10m --poll-interval 2s
```

З `--wait` CLI все одно спочатку викликає `cron.run`, а потім опитує `cron.runs` для поверненого `runId`. Команда завершується з `0` лише тоді, коли запуск завершується зі статусом `ok`. Вона завершується ненульовим кодом, коли запуск завершується з `error` або `skipped`, коли відповідь Gateway не містить `runId`, або коли спливає `--wait-timeout`. `--poll-interval` має бути більшим за нуль.

<Note>
  Використовуйте `--due`, коли хочете, щоб ручна команда виконувалася лише якщо завдання наразі належить виконати. Якщо `--due --wait` не ставить запуск у чергу, команда повертає звичайну відповідь без запуску замість опитування.
</Note>

## Моделі

`cron add|edit --model <ref>` вибирає дозволену модель для завдання. `cron add|edit --fallbacks <list>` задає fallback-моделі для окремого завдання, наприклад `--fallbacks openrouter/gpt-4.1-mini,openai/gpt-5`; передайте `--fallbacks ""` для суворого запуску без fallback. `cron edit <job-id> --clear-fallbacks` видаляє перевизначення fallback для окремого завдання. `cron edit <job-id> --clear-model` видаляє перевизначення моделі для окремого завдання, щоб завдання дотримувалося звичайного пріоритету вибору моделі Cron (збережене перевизначення сеансу Cron, якщо воно є, інакше модель агента/за замовчуванням); його не можна поєднувати з `--model`. `cron add|edit --thinking <level>` задає перевизначення thinking для окремого завдання; `cron edit <job-id> --clear-thinking` видаляє його, щоб завдання дотримувалося звичайного пріоритету thinking Cron, і його не можна поєднувати з `--thinking`.

<Warning>
  Якщо модель не дозволена або її неможливо розв’язати, Cron завершує запуск з явною помилкою валідації замість fallback до агента завдання або вибору моделі за замовчуванням.
</Warning>

Cron `--model` — це **основна модель завдання**, а не перевизначення `/model` сеансу чату. Це означає:

* Налаштовані fallback моделей і надалі застосовуються, коли вибрана модель завдання дає збій.
* Корисне навантаження `fallbacks` для окремого завдання замінює налаштований список fallback, коли воно присутнє.
* Порожній список fallback для окремого завдання (`--fallbacks ""` або `fallbacks: []` у корисному навантаженні/API завдання) робить запуск Cron суворим.
* Коли завдання має `--model`, але список fallback не налаштовано, OpenClaw передає явне порожнє перевизначення fallback, щоб основна модель агента не додавалася як прихована ціль повторної спроби.
* Попередні перевірки локального провайдера проходять налаштовані fallback перед позначенням запуску Cron як `skipped`.

`openclaw doctor` повідомляє про завдання, у яких уже встановлено `payload.model`, включно з кількістю просторів імен провайдерів і невідповідностями з `agents.defaults.model`. Використовуйте цю перевірку, коли поведінка автентифікації, провайдера або білінгу відрізняється між живим чатом і запланованими завданнями.

### Пріоритет моделей ізольованого Cron

Ізольований Cron розв’язує активну модель у такому порядку:

1. Перевизначення Gmail-hook.
2. `--model` для окремого завдання.
3. Збережене перевизначення моделі сеансу Cron (коли користувач вибрав його).
4. Вибір моделі агента або моделі за замовчуванням.

### Швидкий режим

Швидкий режим ізольованого Cron дотримується розв’язаного вибору живої моделі. Конфігурація моделі `params.fastMode` застосовується за замовчуванням, але збережене перевизначення сеансу `fastMode` все одно має перевагу над конфігурацією. Коли розв’язаний режим — `auto`, граничне значення використовує значення `params.fastAutoOnSeconds` вибраної моделі, за замовчуванням 60 секунд.

### Повторні спроби перемикання живої моделі

Якщо ізольований запуск викидає `LiveSessionModelSwitchError`, Cron зберігає переключеного провайдера й модель (а також перевизначення профілю автентифікації після перемикання, якщо воно є) для активного запуску перед повторною спробою. Зовнішній цикл повторних спроб обмежено двома повторними спробами перемикання після початкової спроби, після чого він переривається замість нескінченного циклу.

## Вивід запуску та відмови

### Пригнічення застарілих підтверджень

Ізольовані ходи Cron пригнічують застарілі відповіді, що складаються лише з підтвердження. Якщо перший результат є лише проміжним оновленням статусу, і жоден дочірній запуск субагента не відповідає за остаточну відповідь, Cron один раз повторно надсилає prompt для отримання реального результату перед доставкою.

### Пригнічення мовчазних токенів

Якщо ізольований запуск cron повертає лише беззвучний токен (`NO_REPLY` або `no_reply`), cron пригнічує як пряме вихідне доставлення, так і резервний шлях поставленого в чергу підсумку, тому в чат нічого не публікується.

### Структуровані відмови

Ізольовані запуски cron використовують метадані структурованої відмови у виконанні з вбудованого запуску як авторитетний сигнал відмови. Вони також враховують обгортки `UNAVAILABLE` вузла-хоста, коли вкладене структуроване повідомлення про помилку починається з `SYSTEM_RUN_DENIED` або `INVALID_REQUEST`.

Cron не класифікує прозу фінального виводу або схожі на відмову фрази затвердження як відмови, якщо вбудований запуск також не надає метадані структурованої відмови, тому звичайний текст асистента не вважається заблокованою командою.

`cron list` та історія запусків показують причину відмови замість того, щоб звітувати про заблоковану команду як `ok`.

## Зберігання

Зберігання та очищення керуються в конфігурації:

* `cron.sessionRetention` (за замовчуванням `24h`) очищає завершені ізольовані сеанси запусків.
* `cron.runLog.keepLines` очищає збережені рядки історії запусків SQLite для кожного завдання. `cron.runLog.maxBytes` залишається прийнятним для сумісності зі старішими файловими журналами запусків.

## Міграція старіших завдань

<Note>
  Якщо у вас є завдання cron, створені до поточного формату доставлення та зберігання, запустіть `openclaw doctor --fix`. Команда doctor нормалізує застарілі поля cron (`jobId`, `schedule.cron`, поля доставлення верхнього рівня, зокрема застарілий `threadId`, псевдоніми доставлення `provider` у payload) і мігрує резервні webhook-завдання `notify: true` з `cron.webhook` до явного доставлення через Webhook. Завдання, які вже оголошують у чат, зберігають це доставлення та отримують місце призначення Webhook для завершення. Коли `cron.webhook` не задано, інертний маркер верхнього рівня `notify` видаляється для завдань без цілі міграції (наявне доставлення зберігається без змін), тому `doctor --fix` більше не повторює попередження про них.
</Note>

## Типові редагування

Оновіть налаштування доставлення без зміни повідомлення:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --announce --channel telegram --to "123456789"
```

Вимкніть доставлення для ізольованого завдання:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --no-deliver
```

Увімкніть полегшений початковий контекст для ізольованого завдання:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --light-context
```

Оголосіть у певний канал:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
```

Оголосіть у тему форуму Telegram:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --announce --channel telegram --to "-1001234567890" --thread-id 42
```

Створіть ізольоване завдання з полегшеним початковим контекстом:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron create "0 7 * * *" \
  "Summarize overnight updates." \
  --name "Lightweight morning brief" \
  --session isolated \
  --light-context \
  --no-deliver
```

`--light-context` застосовується лише до ізольованих завдань ходу агента. Для запусків cron полегшений режим залишає початковий контекст порожнім замість вставлення повного початкового набору робочого простору.

Створіть командне завдання з точними argv, cwd, env, stdin і обмеженнями виводу:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron create "*/30 * * * *" \
  --name "Position export" \
  --command-argv '["node","scripts/export-position.mjs"]' \
  --command-cwd "/srv/app" \
  --command-env "NODE_ENV=production" \
  --command-input '{"mode":"summary"}' \
  --timeout-seconds 120 \
  --no-output-timeout-seconds 30 \
  --output-max-bytes 65536 \
  --webhook "https://example.invalid/openclaw/cron"
```

## Типові команди адміністратора

Ручний запуск та перевірка:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron list
openclaw cron list --agent ops
openclaw cron get <job-id>
openclaw cron show <job-id>
openclaw cron run <job-id>
openclaw cron run <job-id> --due
openclaw cron run <job-id> --wait --wait-timeout 10m
openclaw cron run <job-id> --wait --wait-timeout 10m --poll-interval 2s
openclaw cron runs --id <job-id> --limit 50
openclaw cron runs --id <job-id> --run-id <run-id>
```

`openclaw cron list` за замовчуванням показує всі відповідні завдання. Передайте `--agent <id>`, щоб показати лише завдання, чий ефективний нормалізований ідентифікатор агента збігається; завдання без збереженого ідентифікатора агента враховуються як налаштований агент за замовчуванням.

`openclaw cron get <job-id>` повертає збережений JSON завдання напряму. Використовуйте `cron show <job-id>`, коли потрібен зручний для читання вигляд із попереднім переглядом маршруту доставлення.

`cron list --json` і `cron show <job-id> --json` містять поле верхнього рівня `status` для кожного завдання, обчислене з `enabled`, `state.runningAtMs` і `state.lastRunStatus`. Значення: `disabled`, `running`, `ok`, `error`, `skipped` або `idle`. Це віддзеркалює зручний для читання стовпець стану, щоб зовнішні інструменти могли читати стан завдання без повторного обчислення.

Записи `cron runs` містять діагностику доставлення з призначеною ціллю cron, розв’язаною ціллю, надсиланнями інструменту повідомлень, використанням резервного механізму та станом доставлення.

Перенацілювання агента та сеансу:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --agent ops
openclaw cron edit <job-id> --clear-agent
openclaw cron edit <job-id> --session current
openclaw cron edit <job-id> --session "session:daily-brief"
```

`openclaw cron add` попереджає, коли `--agent` пропущено для завдань ходу агента, і повертається до агента за замовчуванням (`main`). Передайте `--agent <id>` під час створення, щоб закріпити конкретного агента.

Налаштування доставлення:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
openclaw cron edit <job-id> --webhook "https://example.invalid/openclaw/cron"
openclaw cron edit <job-id> --best-effort-deliver
openclaw cron edit <job-id> --no-best-effort-deliver
openclaw cron edit <job-id> --no-deliver
```

## Пов’язане

* [Довідник CLI](/uk/cli)
* [Заплановані завдання](/uk/automation/cron-jobs)
