Reschedule a job
Puts a job back on the queue: resets it to pending and clears its executor so the operator re-dispatches it
onto a fresh cluster. This is typically used when a job’s cluster terminated with its step still in flight.
By default this is a no-op for jobs already in a terminal state (completed, cancelled, failed). Supply a
body with force: true to reschedule a terminal job anyway (e.g. to re-run one that already finished). The body
is optional — an empty body keeps the default behavior.
The response’s outcome reports whether the job was actually rescheduled or skipped_terminal (left untouched
because it was terminal and force was not set).
Requires write access to jobs.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Unique identifier for a job.
Body
Optional body for rescheduling a job. May be omitted entirely — an empty body keeps the default behavior, where
rescheduling is a no-op for jobs already in a terminal state (completed, cancelled, failed).
When true, reschedule the job even if it is in a terminal state, resetting it to pending and clearing its
executor so the operator re-dispatches it onto a fresh cluster. Use this to re-run a job that already finished.
When omitted or false, terminal jobs are left untouched.
Response
OK
Result of rescheduling a job — what happened, plus the job's current state afterwards.
What a reschedule call did.
rescheduled— the job was put back on the queue (reset topending, executor cleared).skipped_terminal— the job was left untouched because it was already in a terminal state andforcewas not set.
rescheduled, skipped_terminal 
