> ## Documentation Index > Fetch the complete documentation index at: https://docs.wherobots.com/llms.txt > Use this file to discover all available pages before exploring further. # Monitor and recover > Inspect scheduled runs, recover unprocessed windows, and resume disabled schedules. ## Read run history A task run records an execution attempt or an outcome without execution, such as a skipped or missed time. Script execution uses a Job Run for compute. Open a schedule in [**Scheduled Tasks**](https://cloud.wherobots.com/scheduled-tasks) and inspect its run history. Review the time and window, source, outcome, execution details, and cost. Expand an entry to see earlier attempts. ![Run history filtered to Needs recovery, showing the 1:09 PM to 1:24 PM PST window expanded with 2 attempts: a rerun waiting to start and the earlier scheduled attempt that failed](https://mintcdn.com/wherobots/Me_qzO_IbxOjqKzV/images/develop/task-schedules/monitor-and-recover/needs-recovery.png?fit=max\&auto=format\&n=Me_qzO_IbxOjqKzV\&q=85\&s=302392b46878077d19888db395abfc7d) Needs recovery, with a rerun in progress above the failed scheduled attempt | Task run state | Meaning | | - | - | | `PENDING`, `SUBMITTED` | Accepted or waiting to start. | | `RUNNING` | Execution is in progress. | | `CANCELLING` | Cancellation has been requested. Wait for the terminal outcome. | | `SUCCEEDED` | Execution completed successfully. | | `FAILED` | Execution or admission failed. Inspect `failureClass` and details, for example `USER_CODE` for a script error. | | `TIMED_OUT` | Execution exceeded its time limit. | | `CANCELLED` | Execution was cancelled. | | `REJECTED` | Input validation rejected the run before compute launched or was billed. | | `SKIPPED` | No execution launched: the previous scheduled run was still active (overlap), or the entry records a gap after an edit, a pause, or an automatic disable. Inspect the reason. | | `MISSED` | A scheduled tick passed without a recorded execution. No compute launched. | | `UNKNOWN` | The outcome could not be determined. | A scheduled time that passes without a run appears as `MISSED` after a delay. Missed-time detection doesn't run while a schedule is paused, auto-disabled, or archived. ## Who can manage a schedule Only the schedule's execution identity or an Organization administrator can use **Run now**, **Rerun**, **Pause**, **Resume**, or **Archive**. Other Organization members can view the schedule, but these controls are unavailable to them. New schedules run as you unless an administrator selects a service principal. A service principal is recommended for production work so execution does not depend on an employee's account remaining active. Only Organization administrators can select a service principal, and the Organization must have service principal access. You cannot assign another human as the execution identity. You can't edit a schedule that runs as another person. An administrator can reassign it to a service principal and then edit it. An administrator can also reassign a service-principal schedule to themselves. If the script is in a person's My Files, reassigning the schedule to a service principal also requires changing its script location to `data/shared/` or a storage integration in the same edit. The **Select script file** picker opens on **My Files** even when **Run as** is a service principal; the ownership check happens on save. Saving with a person's My Files script fails with: > The script (definition.uri) must be in the My Files of the principal that runs it. Service principals can't run scripts from a person's My Files. See [Store the script](https://docs.wherobots.com/develop/task-schedules/create-a-schedule.md#store-the-script) for storage choices. ## Edit or stop scheduling Open the schedule's configuration and choose **Edit configuration**, then **Save changes**. See [Processing windows](https://docs.wherobots.com/develop/task-schedules/scripts-and-windows.md#processing-windows) for which edits change execution and how they affect the next window. For the API, use `PATCH /triggers/{triggerId}` with the current `version`. Use **Pause** to stop future scheduled execution while allowing active runs to finish. The API request is `POST /triggers/{triggerId}/pause`; it needs no version. Use **Resume** (`POST /triggers/{triggerId}/resume` with the current `version`) to begin future scheduling again. Resume clears the failure counter and auto-disable state and starts a new [epoch](https://docs.wherobots.com/develop/task-schedules/scripts-and-windows.md#processing-windows). It does not replay a deliberately paused period. Runs dispatched before the reset cannot change the new failure streak. ## Read schedule status The API returns these fields from `GET /triggers/{triggerId}`. In the Cloud UI, the status badge shows **Active** for an active schedule, and **Next run** shows its next scheduled time. | Field | Description | | - | - | | `state` | `ACTIVE`, `PAUSED`, `AUTO_DISABLED` (stopped after repeated failures), or `ARCHIVED`. The `paused` request field doesn't appear in the response; read `state` instead. | | `runAs` | The principal that task runs execute as. Task runs report the same principal as `runAsId`. | | `nextFireTime` | The next scheduled time. It is `null` while the schedule is paused or disabled. It is also `null` while `converged` is `false`, for a few seconds after you create, edit or resume an active schedule. | | `converged` | Whether the scheduler has picked up the schedule's current configuration. To read `nextFireTime` after a change, poll `GET /triggers/{triggerId}` until `converged` is `true`. | | `version` | The schedule's current version. Send it when you update, resume or archive the schedule. | ## Handle version conflicts Before a versioned update, resume, or archive request, read `GET /triggers/{triggerId}` and review the current configuration and `version`. Send that version with your request. Treat the version as an opaque concurrency token: lifecycle actions and failure-counter updates can change it too. It is not a version of the script's contents. If the request returns `409`, read the schedule again. Compare it with the configuration you intended to change, re-evaluate the action, and retry with the latest version only if it is still appropriate. Avoid an unconditional retry loop that overwrites another person's edits. ## Recover a window See [Who can manage a schedule](#who-can-manage-a-schedule) for access requirements. **1. Find the window** Select **Needs recovery** in run history to find unprocessed work, including failed, timed-out, rejected, missed, or skipped entries, plus reruns still in progress. Use **All** to inspect the rest of the history. **2. Fix the cause** Inspect the reason and fix the script, permissions, or configuration before retrying. **3. Rerun the window** Choose **Rerun** on a terminal entry. Review the original window and confirm. **4. Verify the new attempt** Follow the new attempt to completion. Earlier attempts remain in history. A rerun uses the original window and the current script definition, inputs, and execution identity. It is billed as a normal run. The source file is not pinned, so a rerun cannot promise historical code replay. Use [repeatable, window-based output writes](https://docs.wherobots.com/develop/task-schedules/scripts-and-windows.md#write-repeatable-outputs) to avoid duplicates. You can rerun a successful entry too, and reruns are available while a schedule is paused or auto-disabled. Different historical windows can run concurrently, but an active attempt for the same tick or gap must finish before another can start. Archived schedules cannot run again. **Run now** creates a separate manual run and does not repair the journal. ## Failure emails Scheduled failures caused by user code, timeout, rejected configuration, or an unclassified failure send notifications. Platform failures, quota rejections, cancellations, and skipped ticks do not send these failure emails. Manual-run and rerun failures do not send them either. Wherobots sends these emails to the schedule's explicit notification contacts and its active human execution identity. If neither provides a recipient, it uses Organization administrators. A failure that disables the schedule sends a combined failure and auto-disable notice with a link to review it. ## Automatic disabling Wherobots automatically disables a schedule after **5 consecutive counted failures**. The counter counts scheduled user-code, timeout, configuration, and unclassified failures in completion order. Platform failures, quota rejections, and cancellations leave it unchanged. Among runs, only scheduled runs affect the counter. A successful scheduled run clears it. Manual runs and reruns leave it unchanged, whether they succeed or fail. No successful run resumes a paused or auto-disabled schedule. See [Edit or stop scheduling](#edit-or-stop-scheduling) for how **Resume** resets scheduling and the counter. To recover an auto-disabled schedule, inspect its failing run, correct the problem, and test with **Run now** if needed. Then choose **Resume** to restart scheduled execution. Unlike a deliberate pause, the time the schedule spent auto-disabled is recorded as a gap after you resume, so you can rerun it. Rerun any recorded windows that still need recovery. ## Cancel or archive Use **Cancel** on an active run to request cancellation, then check its terminal status. Cancellation does not itself pause future scheduling. Use **Archive** (`DELETE /triggers/{triggerId}?version=N` in the API) to stop future scheduling and request cancellation of active runs, including manual runs and reruns. Configuration and run history remain available in the **Archived** view. An archived schedule cannot be edited, resumed, or rerun. Create a new schedule if the work needs to restart. ## Troubleshooting * **Run now, Rerun, or Resume is unavailable:** check the execution identity and the displayed reason. A deleted execution identity or unavailable service-principal execution prevents these actions. Ask an Organization administrator to review access and the schedule's **Run as** setting. Archived schedules cannot be resumed. * **The script path was accepted, but the run failed:** create-time validation does not prove that the object exists. Check the file at the saved S3 location and confirm the execution identity can read it. A missing path can fail at run time as a user-code error. * **The next scheduled time is unavailable after a change:** allow the scheduler to apply the configuration. The API exposes this as [`converged`](#read-schedule-status). * **A run was rejected for quota:** inspect Organization capacity before rerunning the window. Quota rejections do not increment the failure counter. * **A successful Run now didn't restart an auto-disabled schedule:** manual runs don't change the failure counter or the auto-disable state. Choose **Resume** to restart scheduling. ## Next steps > [card] [Scripts and processing windows](https://docs.wherobots.com/develop/task-schedules/scripts-and-windows.md) > > Make scripts safe to rerun for the same window. > [card] [Create a schedule](https://docs.wherobots.com/develop/task-schedules/create-a-schedule.md) > > Set up a new schedule in Cloud or through the API. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.