Skip to main content
Jobs creates, fetches, and lists dynamic jobs: scheduled functions your code registers at run time, such as a reminder for the end user who is talking to the agent. A dynamic job runs as the end user who created it, so job.user() works inside it. Jobs you ship with the agent are declared with LuaJob; both kinds receive the JobInstance documented here. Available in tools, jobs, webhooks, triggers, and processors. Verified against lua-cli 3.33.0.

Quick example

Methods

create()

Creates a dynamic job with version 1.0.0 and, by default, activates it.
string
required
Base name. The platform appends a timestamp so repeated creations never collide: <name> - <ms since epoch> in deployed agents, <name>_<ms since epoch> in lua test. Match on a prefix (job.name.startsWith('meeting-reminder')), never on equality.
string
Free text stored with the job.
JobSchedule
required
One of { type: 'cron', expression, timezone? }, { type: 'once', executeAt: Date | string }, or { type: 'interval', seconds }. Typed any on this method; JobSchedule is the shape the platform accepts.
(job: JobInstance) => Promise<any>
required
Runs on every occurrence with the job’s handle. The function is stored as its source text, so variables from the enclosing scope are not captured; pass values through metadata and read them from job.metadata. When created from deployed tool, job, webhook, or processor code, the function runs inside that code’s compiled bundle and module-level imports resolve. In lua test it is stored on its own, so use only metadata and the runtime objects (User, Data, Channels, and the others) inside it.
number
Maximum run time in seconds, from 1 to 600.
{ maxAttempts: number; backoffSeconds?: number }
Retries after a failed attempt, a timed-out one included, while maxAttempts allows. Each retry waits a fixed backoffSeconds (default 60; 0 is treated as 60), with no jitter, and the platform stops after 10 attempts whatever maxAttempts says.
Record<string, any>
JSON stored with the job and available as job.metadata.
boolean
default:true
Whether the job starts running on its schedule at once.
Returns — the created job as a JobInstance. Example
ErrorsFailed to create job (lua test) or Failed to create job: <reason> (deployed) when the platform rejects the configuration, for example a timeout outside 1 to 600.

getJob()

Returns one job by id.
Returns — the job as a JobInstance. An unknown id throws; there is no null return. Example
ErrorsFailed to get job (lua test) or Failed to get job: <reason> (deployed).

getAll()

Returns the agent’s jobs.
boolean
default:false
false lists only jobs declared with LuaJob; true adds jobs created with Jobs.create().
Returns — an array of JobInstance. Example
ErrorsFailed to get all jobs.

JobInstance

The handle create(), getJob(), and getAll() return, and the argument every job’s execute receives.
string
Job id.
string
The stored name, including the platform’s timestamp suffix for dynamic jobs.
JobVersion
The active version: id, version, schedule, timeout, retry, metadata, active, createdAt, and updatedAt. Absent when no version is active.
Record<string, any>
The job’s metadata.
Job
The full record: id, name, description, agentId, active, status (active, paused, failed, or inactive), activeVersionId, versions, dynamic, userId, lastRunAt, nextRunAt, lastExecution, createdAt, and updatedAt.
{ executionId: string; attempt: number; occurrenceId: string; scheduledTime?: string }
Attempt information for the current run, set on every deployed run; see Retries and idempotency.

updateMetadata()

Merges fields into metadata locally and stores the merged object.
ErrorsFailed to update job metadata, or the platform’s message.

delete()

Deletes the job, or deactivates it when it has versions.
Example
ErrorsFailed to delete job, or the platform’s message.

user()

Returns the end user recorded on the job: the end user who created a dynamic job, or the developer who pushed a job declared with LuaJob.
Returns — the recorded end user as a UserDataInstance. To act on a specific end user from a declared job, use User.get(id) instead. ErrorsUser API not initialized when the job record carries no userId.

trigger()

Runs the job immediately, outside its schedule.
string
A version to run. Defaults to the active version.
Returns
JobExecution
id, jobId, versionId, status, startedAt, and, once finished, completedAt, duration, result, error, and retryCount. status is one of pending, claimed, running, cancellation_requested, completed, failed, timeout, killed, cancelled, abandoned, or reaped.
Three of those statuses are set by the platform rather than by your code. killed is an attempt the platform closed because it ran past its wall-clock budget and grace period; it counts as a failure and is retried under retry. reaped is an attempt whose worker stopped renewing its lease, so the worker is gone; it is not retried, and the next scheduled occurrence runs as normal. abandoned is an attempt fenced by a forced cancel after a cooperative cancel went unanswered for 10 minutes; it is not retried, and a late result from the run no longer changes the record. A timed-out attempt is recorded as failed, not timeout. ErrorsFailed to trigger job, or the platform’s message.

activate()

Lets the job run on its schedule.
ErrorsFailed to activate job, or the platform’s message.

deactivate()

Stops the job from running on its schedule without deleting it.
Example
ErrorsFailed to deactivate job, or the platform’s message.

toJSON()

Returns the full record with id, name, activeVersion, and metadata merged in.

Retries and idempotency

A job runs at least once per occurrence. A failed attempt, a timed-out one included, is retried according to retry while maxAttempts allows: each retry waits a fixed backoffSeconds (default 60), with no jitter, and the platform stops after 10 attempts whatever maxAttempts says. A single occurrence can therefore run more than once. The running handle’s execution tells the attempts apart: occurrenceId stays constant across every attempt of one occurrence, executionId is minted per attempt, attempt starts at 1, and scheduledTime is the schedule slot for scheduled runs only.
Deployed runs only. execution is set on the handle every deployed run receives, is undefined in lua test, and is not declared on JobInstance in lua-cli 3.33.0, so read it through a cast and treat it as optional.

Types

Jobs, JobInstance, and JobSchedule are exported. Job, JobVersion, and JobExecution are not; name them from the handle.

See also

  • LuaJob — jobs shipped with the agent, and the JobSchedule type
  • About jobs — dynamic jobs versus LuaJob, schedules, timeouts, and delivery
  • Schedule a recurring job — how-to
  • User — what job.user() returns
  • lua jobs — inspect, trigger, and deactivate jobs from the CLI