---
read_when:
    - Вам потрібні заплановані завдання та пробудження
    - Ви налагоджуєте виконання Cron і журнали
summary: Довідник CLI для `openclaw cron` (планування та запуск фонових завдань)
title: Cron
x-i18n:
    generated_at: "2026-05-11T20:27:04Z"
    model: gpt-5.5
    provider: openai
    source_hash: ad261871e48704061be7147f0a2722001cdc7e95156c0dc44f46c41d7e415cc6
    source_path: cli/cron.md
    workflow: 16
---

# `openclaw cron`

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

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

## Сеанси

`--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` виконує резервну доставку фінальної відповіді лише тоді, коли агент не надіслав її напряму до розв’язаної цілі.
- `webhook` надсилає завершене навантаження на URL.
- `none` вимикає резервну доставку runner.

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

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

### Доставка помилок

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

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

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

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

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

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

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

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

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

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

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

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

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

Примітка: визначення завдань Cron зберігаються в `jobs.json`, тоді як очікуваний стан середовища виконання зберігається в `jobs-state.json`. Якщо `jobs.json` редагується зовні, Gateway перезавантажує змінені розклади й очищає застарілі очікувані слоти; перезаписи лише форматування не очищають очікуваний слот.

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

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

<Note>
`openclaw cron run <job-id>` за замовчуванням виконує примусовий запуск. Використовуйте `--due`, щоб зберегти старішу поведінку «запускати лише якщо настав час».
</Note>

## Моделі

`cron add|edit --model <ref>` вибирає дозволену модель для завдання.

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

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

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

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

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

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

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

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

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

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

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

### Придушення застарілого підтвердження

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

### Придушення мовчазного токена

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

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

Ізольовані запуски Cron надають перевагу структурованим метаданим відмови у виконанні з вбудованого запуску, а потім повертаються до відомих маркерів відмови у фінальному виводі, таких як `SYSTEM_RUN_DENIED`, `INVALID_REQUEST` і фрази відмови прив’язки схвалення.

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

## Утримання

Утримання й обрізання керуються в конфігурації:

- `cron.sessionRetention` (за замовчуванням `24h`) обрізає завершені сеанси ізольованих запусків.
- `cron.runLog.maxBytes` і `cron.runLog.keepLines` обрізають `~/.openclaw/cron/runs/<jobId>.jsonl`.

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

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

## Поширені редагування

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

```bash
openclaw cron edit <job-id> --announce --channel telegram --to "123456789"
```

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

```bash
openclaw cron edit <job-id> --no-deliver
```

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

```bash
openclaw cron edit <job-id> --light-context
```

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

```bash
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
```

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

```bash
openclaw cron edit <job-id> --announce --channel telegram --to "-1001234567890" --thread-id 42
```

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

```bash
openclaw cron add \
  --name "Lightweight morning brief" \
  --cron "0 7 * * *" \
  --session isolated \
  --message "Summarize overnight updates." \
  --light-context \
  --no-deliver
```

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

## Поширені команди адміністратора

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

```bash
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 runs --id <job-id> --limit 50
```

`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, розв’язаною ціллю, надсиланнями інструмента message, використанням резервної доставки та станом доставки.

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

```bash
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
openclaw cron edit <job-id> --announce --channel slack --to "channel:C1234567890"
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)