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 version1.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.
JobInstance.
Example
Failed 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.JobInstance. An unknown id throws; there is no null return.
Example
Failed 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().JobInstance.
Example
Failed to get all jobs.
JobInstance
The handlecreate(), 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 intometadata locally and stores the merged object.
Failed to update job metadata, or the platform’s message.
delete()
Deletes the job, or deactivates it when it has versions.Failed 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 withLuaJob.
UserDataInstance. To act on a specific end user from a declared job, use User.get(id) instead.
Errors — User 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.
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.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.
Errors — Failed to trigger job, or the platform’s message.
activate()
Lets the job run on its schedule.Failed to activate job, or the platform’s message.
deactivate()
Stops the job from running on its schedule without deleting it.Failed to deactivate job, or the platform’s message.
toJSON()
Returns the full record withid, 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 toretry 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 theJobScheduletype- About jobs — dynamic jobs versus
LuaJob, schedules, timeouts, and delivery - Schedule a recurring job — how-to
User— whatjob.user()returnslua jobs— inspect, trigger, and deactivate jobs from the CLI

