---
{
  "id": "platform.cron.lifecycle-and-replacement",
  "topic": "cron",
  "title": "Cron lifecycle and replacement updates",
  "locale": "en",
  "version": "2026-09-05.1",
  "summary": "Pausing preserves a Cron job, cancelling stops future fires, and updating creates a new job ID linked to the cancelled original.",
  "content": "Cron job statuses are `active`, `paused`, `firing`, `completed`, `cancelled`, `expired`, and `failed`. `set_enabled(false)` pauses an eligible job while preserving its history. `set_enabled(true)` resumes an eligible paused job, clears its consecutive failure/skip counters and first-loss timestamp, removes its cancellation reason, and recomputes the next fire time. `completed`, `cancelled`, `expired`, and `failed` are terminal outcomes and must be interpreted from the current action result.\n\n`update_job` is a replacement, not an in-place row mutation. On success, read the new `cronJobId` from the response and use it for every follow-up. `replacesCronJobId` points to the old job, which is cancelled with reason `system:replaced`. A dry-run response does not prove that a replacement was persisted.\n\n`run_now` requires user confirmation and accepts only `active` or `paused` jobs. It creates a manual fire without changing `nextFireAt`, `runCount`, schedule, or skip counters. Reusing the same idempotency key returns the original result even if the job becomes terminal after the first call.\n\nWeb/API `duplicate` creates a new `active` but disabled draft, clears the dedupe key, and copies no Agent grants beyond the normal floor. This also works for completed once jobs and expired recurring jobs: historical `runAt`, `endAt`, and `expiresAt` are preserved for editing, but the draft cannot be enabled until its schedule has a future occurrence.\n\n`cancel_job` requires user confirmation, then stops future normal fires while retaining history and telemetry; it is not deletion. Terminal `completed`, `expired`, `failed`, and `cancelled` jobs cannot be resumed or cancelled. Update, cancel, and run-now use strict drift checks; update uses `ConfirmationPolicy::None`, while cancel and run-now use `ConfirmationPolicy::UserConfirm`.\n",
  "aliases": [
    "pause cron",
    "resume schedule",
    "replace job",
    "new cronJobId",
    "cancel schedule",
    "system replaced"
  ],
  "tags": [
    "cron",
    "lifecycle",
    "replacement"
  ],
  "relatedActions": [
    "arinova.cron.get_job",
    "arinova.cron.update_job",
    "arinova.cron.set_enabled",
    "arinova.cron.cancel_job",
    "arinova.cron.run_now"
  ],
  "relatedActionPrefixes": [],
  "sourceReviewedAt": "2026-09-06",
  "url": "https://docs.arinova.ai/en/kb/cron/lifecycle-and-replacement/"
}
---

Cron job statuses are `active`, `paused`, `firing`, `completed`, `cancelled`, `expired`, and `failed`. `set_enabled(false)` pauses an eligible job while preserving its history. `set_enabled(true)` resumes an eligible paused job, clears its consecutive failure/skip counters and first-loss timestamp, removes its cancellation reason, and recomputes the next fire time. `completed`, `cancelled`, `expired`, and `failed` are terminal outcomes and must be interpreted from the current action result.

`update_job` is a replacement, not an in-place row mutation. On success, read the new `cronJobId` from the response and use it for every follow-up. `replacesCronJobId` points to the old job, which is cancelled with reason `system:replaced`. A dry-run response does not prove that a replacement was persisted.

`run_now` requires user confirmation and accepts only `active` or `paused` jobs. It creates a manual fire without changing `nextFireAt`, `runCount`, schedule, or skip counters. Reusing the same idempotency key returns the original result even if the job becomes terminal after the first call.

Web/API `duplicate` creates a new `active` but disabled draft, clears the dedupe key, and copies no Agent grants beyond the normal floor. This also works for completed once jobs and expired recurring jobs: historical `runAt`, `endAt`, and `expiresAt` are preserved for editing, but the draft cannot be enabled until its schedule has a future occurrence.

`cancel_job` requires user confirmation, then stops future normal fires while retaining history and telemetry; it is not deletion. Terminal `completed`, `expired`, `failed`, and `cancelled` jobs cannot be resumed or cancelled. Update, cancel, and run-now use strict drift checks; update uses `ConfirmationPolicy::None`, while cancel and run-now use `ConfirmationPolicy::UserConfirm`.