Pause and recover customer-scheduled work
How to stop scheduled requests, check on work already submitted, and restore only the access you need after a problem.
Choose the control
Open the controls for your existing customer scheduler or event handler. Choose the action by the effect you need:
| Control | Stops or changes | Verify it by reading |
|---|---|---|
| Pause | Future triggers and pending retries in the customer scheduler | Saved scheduler state and run history, then any request that raced with the pause |
| Cancel | Admitted Compute work, through its supported job operation | The resulting job state and any accepted result or receipt |
| Revoke | The exact credential, transfer permission or webhook grant at its source | The grant's resulting state and the destination or prior copies separately |
Pausing, canceling and revoking have different owners and do not substitute for one another.
Keep the current template version, occurrence records, submission keys, and job references while investigating. Do not delete the recovery record or start another scheduler to work around the problem.
Pause future triggers
Disable the affected timer or event rule in its owning system, then check pending submission retries there as well. Pausing a future timer alone may leave a previously queued request or retry active.
Confirm the saved setting and inspect the scheduler's existing run history. Reconcile any request that raced with the pause. An acknowledgment from the scheduler does not prove that no request reached Compute.
This pause is a customer-side control. It does not change a Lithi schedule resource, cancel an admitted job, erase a result or refund accepted work. Verify both the saved pause and pending retries; an acknowledgment alone does not prove that no request reached Compute.
Cancel admitted work
Read the known job or batch through the normal Compute workflow. Separate accepted work, unresolved submissions and work that was never admitted. Do not treat an empty local history entry as proof that a remote request failed.
If admitted work must stop, request cancellation through the job's supported operation. Read the resulting job state rather than assuming the request stopped all execution immediately. Keep already accepted results and relevant receipts available for review. Cancellation does not undo accepted work or a destination write.
A destination operation may also be in progress. Inspect its own outcome before retrying or disabling access. Changing a credential does not undo an output object that was already written.
Revoke the exact grant
Use the existing credential or service administration controls for the exact grant you intend to revoke. A scheduler setting, storage credential, Compute work key and webhook verification secret have different owners.
Remove only the affected permission and confirm its resulting state. Do not broaden another grant to compensate for an expired one. Never place secret values in the incident record, a copied prompt or a support message. Revocation does not cancel a job or erase a file that was already exported.
Follow result retention and deletion for previously exported files and destination copies. Revocation is not evidence that a past job was canceled.
Review recovery before resuming
Check the failure's cause while the trigger remains disabled. Confirm the exact input snapshot, workflow and operation, processing profile, output destination and named credential references. If the approved input no longer exists, review a replacement rather than silently using current data.
Keep the prepared brief with that review: frozen instructions and rubric, input IDs, output schema, required evidence and acceptance rule. A scheduler can replay a recorded occurrence, but it cannot broaden the task instructions, release a broader data set or spend beyond the approved scope.
Review the current quote and approval requirements for new work. A stored template or a previously approved occurrence does not authorize a wider task or spend bound after a pause.
Confirm the current data scope, budget ceiling, timing policy and change-approval rule before resuming. Your agent can prepare the reviewed request; the responsible person or bounded approval policy still controls whether new paid work may be submitted.
Check the time zone, next intended times, overlap, allowed lateness, and catch-up limit in the scheduler. Choose explicitly which missed occurrences to skip or recover. Do not enable an unbounded backlog.
Resume without changing old identities
Recovering an unresolved existing occurrence preserves its original submission association. Deliberately new work receives a new occurrence and review. Resuming a scheduler does not mean every recovery must use a new identity.
Re-enable only the reviewed trigger or finite recovery selection. Inspect its first intended occurrence, any admitted job, the accepted result, and the destination outcome. Check returned coverage, uncertainty and schema against the prepared brief before synthesis. If behavior differs from the reviewed settings, pause again and reconcile that occurrence before another request.
For a failed destination write after Compute succeeds, follow delivery recovery without rerunning work. Verify the existing result and recover only the failed delivery step.
Next, review native job cancellation when admitted work also needs to stop.