---
read_when:
    - Вам нужны запланированные задания и пробуждения
    - Вы отлаживаете выполнение Cron и журналы
summary: Справочник CLI для `openclaw cron` (планирование и запуск фоновых заданий)
title: Cron
x-i18n:
    generated_at: "2026-07-01T08:21:49Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: aed39843e183b3d441908ad4ac0578d44b6f0d482905871efc3421fd9820a1cc
    source_path: cli/cron.md
    workflow: 16
---

# `openclaw cron`

Управляйте Cron-задачами для планировщика Gateway.

<Tip>
Запустите `openclaw cron --help`, чтобы увидеть полный набор команд. См. [Cron-задачи](/ru/automation/cron-jobs) для концептуального руководства.
</Tip>

## Быстрое создание задач

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

```bash
openclaw cron create "0 7 * * *" \
  "Summarize overnight updates." \
  --name "Morning brief" \
  --agent ops
```

Используйте `--webhook <url>`, когда задача должна отправить завершенный payload через POST вместо доставки в целевой чат:

```bash
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
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` создает новый transcript и идентификатор сессии для каждого запуска.
    - `current` привязывает к активной сессии на момент создания.
    - `session:<id>` закрепляет за явным постоянным ключом сессии.

  </Accordion>
  <Accordion title="Семантика изолированной сессии">
    Изолированные запуски сбрасывают окружающий контекст беседы. Маршрутизация каналов и групп, политика отправки/очереди, elevation, origin и привязка runtime ACP сбрасываются для нового запуска. Безопасные предпочтения и явно выбранные пользователем переопределения модели или auth могут переноситься между запусками.
  </Accordion>
</AccordionGroup>

## Доставка

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

Цели с префиксом провайдера могут устранять неоднозначность неразрешенных каналов announce. Например, `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` отправляет завершенный payload на URL.
- `none` отключает резервную доставку 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`, который только отключает резервную доставку runner, эти флаги удаляют сохраненное поле, чтобы задача снова разрешала эту часть маршрута из значений по умолчанию.

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

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

### Доставка при сбоях

Уведомления о сбоях разрешаются в следующем порядке:

1. `delivery.failureDestination` в задаче.
2. Глобальный `cron.failureDestination`.
3. Основная цель announce задачи (когда явное место назначения для сбоев не задано).

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

Примечание: изолированные cron-запуски рассматривают ошибки агента на уровне запуска как ошибки задачи, даже когда
payload ответа не создан, поэтому сбои модели/провайдера все равно увеличивают счетчики ошибок
и запускают уведомления о сбоях.

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

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

## Планирование

### Одноразовые задачи

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

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

### Повторяющиеся задачи

Повторяющиеся задачи используют экспоненциальную задержку повторов после последовательных ошибок: 30s, 1m, 5m, 15m, 60m. После следующего успешного запуска расписание возвращается к нормальному режиму.

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

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

Примечание: Cron-задачи, ожидающее runtime-состояние и история запусков находятся в общей базе данных состояния 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
openclaw cron run <job-id>
openclaw cron runs --id <job-id> --run-id <run-id>
```

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

```bash
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>` задает резервные модели для конкретной задачи, например `--fallbacks openrouter/gpt-4.1-mini,openai/gpt-5`; передайте `--fallbacks ""` для строгого запуска без резервных вариантов. `cron edit <job-id> --clear-fallbacks` удаляет переопределение резервных моделей для задачи. `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 завершает запуск с явной ошибкой валидации вместо отката к выбору агента задачи или модели по умолчанию.
</Warning>

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

- Настроенные резервные модели по-прежнему применяются, когда выбранная модель задачи дает сбой.
- Payload `fallbacks` для конкретной задачи заменяет настроенный список резервных моделей, когда присутствует.
- Пустой список резервных моделей для задачи (`--fallbacks ""` или `fallbacks: []` в payload/API задачи) делает cron-запуск строгим.
- Когда у задачи есть `--model`, но список резервных моделей не настроен, OpenClaw передает явное пустое переопределение резервных моделей, чтобы основная модель агента не добавлялась как скрытая цель повторной попытки.
- Preflight-проверки локального провайдера обходят настроенные резервные модели перед тем, как пометить cron-запуск как `skipped`.

`openclaw doctor` сообщает о задачах, у которых уже задан `payload.model`, включая счетчики пространств имен провайдеров и несоответствия с `agents.defaults.model`. Используйте эту проверку, когда поведение auth, провайдера или billing отличается между живым чатом и запланированными задачами.

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

Изолированный cron разрешает активную модель в следующем порядке:

1. Переопределение Gmail-hook.
2. `--model` для конкретной задачи.
3. Сохраненное переопределение модели cron-сессии (когда пользователь выбрал его).
4. Выбор модели агента или модели по умолчанию.

### Быстрый режим

Быстрый режим изолированного cron следует разрешенному выбору живой модели. Конфигурация модели `params.fastMode` применяется по умолчанию, но сохраненное переопределение сессии `fastMode` все равно имеет приоритет над конфигурацией. Когда разрешенный режим равен `auto`, cutoff использует значение `params.fastAutoOnSeconds` выбранной модели, по умолчанию 60 секунд.

### Повторные попытки при переключении live-модели

Если изолированный запуск выбрасывает `LiveSessionModelSwitchError`, cron сохраняет переключенного провайдера и модель (а также переопределение переключенного профиля auth, когда оно присутствует) для активного запуска перед повторной попыткой. Внешний цикл повторов ограничен двумя повторными попытками переключения после начальной попытки, затем прерывается вместо бесконечного цикла.

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

### Подавление устаревших подтверждений

Изолированные ходы cron подавляют устаревшие ответы, состоящие только из подтверждения. Если первый результат — это лишь промежуточное обновление статуса и ни один дочерний запуск subagent не отвечает за итоговый ответ, cron один раз повторно запрашивает реальный результат перед доставкой.

### Подавление silent token

Если изолированный запуск 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
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 create "0 7 * * *" \
  "Summarize overnight updates." \
  --name "Lightweight morning brief" \
  --session isolated \
  --light-context \
  --no-deliver
```

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

Создать командную задачу с точными argv, cwd, env, stdin и лимитами вывода:

```bash
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
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>`, чтобы показать только задачи, чей фактический нормализованный id агента совпадает; задачи без сохраненного 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
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` опущен для задач agent-turn, и возвращается к агенту по умолчанию (`main`). Передайте `--agent <id>` при создании, чтобы закрепить конкретного агента.

Настройки доставки:

```bash
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](/ru/cli)
- [Запланированные задачи](/ru/automation/cron-jobs)
