Skip to main content
Scheduled tasks execute prompts inside Harness and persist definitions, execution state, and results in TOS. Use them for recurring reports, checks, and one-time work

Enable scheduled tasks

Keep at least one runtime instance active, which incurs capacity and TOS charges. Task prompts and resolved MCP credentials are stored in TOS; restrict bucket access. The deployment identity needs permission to create or attach a TOS policy scoped to the task storage prefix on the runtime role
Prepare an existing TOS bucket, then run from the project containing harness.yaml
harness.yaml
For BytePlus, use cloud.provider: byteplus, the matching runtime region and TOS bucket, or global --provider byteplus when deploying. Supply the bucket name rather than its URL. This version supports service-authenticated Harnesses, such as API-key deployments; shared OAuth Harnesses do not support background tasks After deployment, run agentkit harness cronjob status my-harness to confirm scheduling and storage are available before creating a task. The response describes the responding replica, not aggregate health across all replicas

Commands

harness cronjob create

Create a recurring or one-time task
The response includes cronjob_id. The same idempotency key and input return the same task; changed input is rejected. For one-time work, replace --cron with a future timestamp such as --at "2026-10-01T09:00:00+08:00". --config uses the message, harness, and model call limit from Harness invocation configuration; omitted fields inherit the deployment Save the actual cronjob_id returned by creation for the detail, pause, and history commands below

harness cronjob list

List task definitions and current status
Pass the returned next_cursor to --cursor for the next page

harness cronjob status

Show scheduler health for the responding replica

harness cronjob get

Get a scheduled task

harness cronjob pause

Pause future scheduling and queued executions without stopping an active execution

harness cronjob resume

Resume a paused task

harness cronjob runs

List execution history, newest first
Pass the returned next_cursor to --cursor for the next page Select a run_id from the history returned by runs, then read that execution’s result. A task ID and execution ID are not interchangeable

harness cronjob result

Read an execution result

harness cronjob cancel

Request execution cancellation

Scheduling, recovery, and results

  • Each execution gets its own session, and final results remain in TOS across restarts
  • An occurrence is recorded as skipped if the previous execution of that task is still active
  • latest runs the most recent missed occurrence once. skip runs it only within --grace; older missed occurrences are not replayed individually
  • Failures and timeouts are not retried automatically; later scheduled occurrences can still run
  • A stopped worker or lost lease marks the execution interrupted and pauses the task. Inspect external effects before resuming recurring work or creating a replacement one-time task
  • Pausing does not terminate active work. Cancellation is checked during lease renewal, normally within about 20 seconds with the default lease
  • status describes only the responding replica. History is newest first; during the brief history-save interval, results can appear in get or result before runs
External effects are not guaranteed to occur exactly once: a worker can stop immediately after a tool writes to an external system. Check completed effects before recovery to avoid repeating them. Scheduling scans retained tasks, so adjust polling for task volume and TOS request traffic Pause a task to stop future scheduling. Cancellation targets one run_id and does not change the recurring schedule. Recheck execution status after requesting cancellation; completed external actions are not rolled back. This CLI has no subcommand to delete a task definition; use pause to stop future runs
Last modified on September 19, 2026