lhc jobs
Manage Lakehousecat job definitions and job runs. Job definitions are scheduled or on-demand automation tasks.
Commands
jobs list
List all job definitions:
lhc jobs list
jobs get <id>
Get a job definition by ID:
lhc jobs get <definition-id>
jobs trigger <definition-id>
Start a job run for a given definition:
lhc jobs trigger <definition-id>
Returns the created job run object, including its id (run ID) for status polling.
jobs status <run-id>
Get the current status of a job run:
lhc jobs status <run-id>
jobs runs
List job runs, newest first:
lhc jobs runs [--limit N] [--offset N] [--all-users]
lhc jobs runs --limit 20
| Flag | Default | Description |
|---|---|---|
--limit | 50 | Maximum number of runs (not capped; fetched in chunks) |
--offset | 0 | Number of runs to skip |
--all-users | off | [Admin only] runs of all users instead of only your own |
A full window ends with a "there may be more" note on stderr — the endpoint reports no total.
jobs search [query]
Search job definitions by name, description, type, or schedule:
lhc jobs search sync
lhc jobs search sync --type semantic_extraction
lhc jobs search --tag RED # every red job definition, across all pages
| Flag | Description |
|---|---|
--type | Filter by job type |
--tag | Restrict to job definitions tagged with this color (repeatable, OR-combined; valid colors: RED, YELLOW, GREEN, BLUE, PURPLE). Tags are per user and assigned in the UI — the CLI only filters by them |
The query is optional when --tag is given, but at least one of the two is required.
Job runs have their own search — see jobs runs search below.
jobs runs search [query]
Search matches the archived job definition name, the Airflow DAG or run ID, or the job type. The definition name is kept on the run itself, so a run stays findable by search even after its definition was deleted.
lhc jobs runs search extraction
lhc jobs runs search extraction --status failed
lhc jobs runs search --tag RED # every red run, across all pages
| Flag | Description |
|---|---|
--type | Filter by job type |
--status | Filter by current run status |
--tag | Restrict to runs tagged with this color (repeatable, OR-combined; valid colors: RED, YELLOW, GREEN, BLUE, PURPLE). Tags are per user and assigned in the UI — the CLI only filters by them |
The query is optional when --tag is given, but at least one of the two is required.
jobs share <id>
Share a job definition with a user or group. Exactly one of --user or --group is required:
lhc jobs share 42 --user 3e7c3d4f-16ff-4914-8250-bbe693ab7224
lhc jobs share 42 --group 1 --permission write
| Flag | Default | Description |
|---|---|---|
--user | — | Target user ID (UUID) |
--group | — | Target group ID (integer) |
--permission | read | Permission level: read, write, owner |
jobs unshare <id>
Remove a share from a job definition:
lhc jobs unshare 42 --user 3e7c3d4f-16ff-4914-8250-bbe693ab7224
lhc jobs unshare 42 --group 1
jobs shared-by-me / jobs shared-with-me
List job definitions you have shared with others, or job definitions others have shared with you:
lhc jobs shared-by-me
lhc jobs shared-with-me
jobs cancel <run-id>
Cancel a running job run (Admin only). The run is stopped in the scheduler and marked as cancelled. The command fails if the run does not exist, is not in a cancelable state, or the scheduler rejects the request:
lhc jobs cancel 42
Managing job definitions
Creating, updating, and deleting job definitions is restricted to Admins and Builders.
jobs create
Create a job definition from a YAML or JSON manifest. The manifest holds the name, description, job type, CRON schedule, the task content (task IDs, worker types, environment variables, secret references, resources, upstream dependencies), and the visibility/lock flags:
lhc jobs create -f job.yaml
lhc jobs create -f job.yaml --name "Nightly Sync" --schedule "0 2 * * *"
| Flag | Required | Description |
|---|---|---|
-f, --file | yes | Path to a YAML or JSON manifest |
--name | no | Override the manifest's name |
--description | no | Override the manifest's description |
--type | no | Override the job type, e.g. BUILDER_TASK |
--schedule | no | Override the CRON schedule |
--is-enabled, --is-locked, --is-visible | no | Override the corresponding flag |
The scalar flags only override top-level fields — the nested task content always comes from the
manifest. A task with the admin worker type requires an Admin caller, both when creating and
when updating it later.
jobs update <id>
Update a job definition, either from a manifest (partial — only the fields present are changed)
or via the same scalar flags as create. At least one of --file or a scalar flag is required:
lhc jobs update 42 --schedule "0 3 * * *"
lhc jobs update 42 --is-enabled=false
lhc jobs update 42 -f job.yaml
Changing the task content requires --file. Built-in job definitions may reject certain field
changes on the server side.
jobs delete <id>
lhc jobs delete 42
Built-in job definitions cannot be deleted and return a 403. Deactivate them instead:
lhc jobs update <id> --is-enabled=false