# Scheduler Everything that runs on a timer is decided here. The page is the front end for two files: `schedule.json` holds when things fire, and `master.conf` holds which steps an orchestrator actually calls. Every control below writes to one of those two — nothing on this page needs a conf file opened by hand. **An orchestrator is a job that calls other scripts in order.** The orchestrator has the cron entry; its steps do not. That one fact explains most of the behaviour below. --- ## Stopping one step without disabling the whole job The common case: a nightly job is fine, but one script inside it should stop running. 1. Find the orchestrator's card — for example **Daily Sync Maintenance**. 2. Click **Steps ▸** on the right of its row. The list of scripts it calls expands. 3. Toggle off the one you want stopped. The orchestrator keeps running on its schedule and simply skips that step. Under the hood the toggle comments the script out of that orchestrator's array in `master.conf`, which is the same edit you would make by hand — the toggle is just the safe way to make it. Turn it back on with the same toggle. The commented line is left in place, so the step keeps its position in the sequence rather than being appended to the end. > The button is called **Steps**, not Advanced. There is a separate **Advanced** button at the > top right of the panel that does something quite different — see *Advanced mode* below. ## Turning an orchestrator off entirely Toggle the orchestrator itself off. Its cron entry stops firing and **every step inside it is suppressed** — an enabled step under a disabled orchestrator does not run, because the orchestrator is what calls it. If you still want one of those scripts running while its orchestrator is off, give that step its own cron expression. With the orchestrator off, a step's cron field becomes live and it fires standalone. ## Running something right now **Run** fires the script immediately and resets its cron timer, so the next scheduled fire is a full interval later rather than a few minutes away. **Dry Run** passes `--dry-run`. Nothing is written to disk, and the full output is shown rather than a summary — with the cleanup scripts, reading the list of what *would* be removed is the entire point. Anything destructive offers both, and Run asks for confirmation first. ## Changing when something runs Type into the cron field. It saves when the field loses focus, shows the schedule back to you in plain English, and turns red if the expression is invalid. Two shortcuts worth knowing: - **Suggested cron** — in the Orch tree on the right, each script shows a suggested cron badge. Click it to apply and save that schedule instantly. - **Cron Calculator** — accepts an expression or plain English, shows a description plus the next five fire times, and **Apply** pushes it into the cron field you last used. For array events, put `array_start` or `array_stop` in the cron field instead of an expression. A badge appears and the script fires on Unraid's array start or stop. This works for any orchestrator or custom script. ## Finding out why something failed **Log** opens that script's log in the right-hand panel. It auto-scrolls to the newest line, pauses when you scroll up, and resumes when you return to the bottom. **Invert** puts newest lines at the top. The **Search** box in the toolbar filters and highlights matches while dimming everything else. Two blocks on the Scheduler Info panel get you there faster: - **Recent Activity** — the last 24 runs. Click any row to open that log. Expands itself when there are errors. - **Recent Errors** — the most recent error per script over 7 days, so a failure that happened once at 3am is still visible days later. The status dot in the Orch tree is green, orange or red for the last run's outcome, dim if the script has never run. Hover for detail. ## Asking the assistant about what is on screen The panel below the right-hand views is the same chat component the AI tab and the Monitor dashboard use, at this panel's size. What is particular to this tab is that its subject follows you: open a log, a conf or a script and the chip states both the profile answering and the thing it is pointed at. Nothing is inferred silently — if what the chip says is wrong, that costs a glance rather than a confidently wrong answer. Every row in **Recent Activity** carries a **why?** (failed) or **recap** (clean) button. It opens that script's log first and then asks, because the question is only worth asking with the log attached — the profile that reads it is the one that gets the log tail. The question is posted as visible text, so what was asked on your behalf is never a mystery. Moving to a different subject keeps the transcript on screen but stops sending the earlier turns to the model, and starts a new stored conversation. A troubleshooting thread carrying log excerpts must not bleed into a question about a conf key; hiding that the earlier exchange happened would be worse than carrying it visibly. Reasoning is enabled only for Troubleshoot. Working out what a log means is worth waiting for; a lookup like "what does this setting do" is not, and an inline answer that stalls reads as broken. ## Recording what actually fixed something When a diagnosis is followed by that same script running clean, the assistant offers to record it: *"`