--- title: Scheduler (Automation Jobs Center) description: The control room for TSync's background jobs — currency refresh, low-stock scans, scheduled report e-mails, workflow checks: see runs, failures and locks, and run a job now. product: TSync Intelligence 11.3.6 language: en canonical: https://docs.tsync.pro/scheduler/ source: https://docs.tsync.pro/llms.txt --- # Scheduler (Automation Jobs Center) The **Scheduler** (`/admin/tsync_scheduler`) is the control room for the background jobs that keep TSync running — the daily currency refresh, low-stock scans, scheduled report e-mails, workflow due-checks and more. It does not replace your server's [cron job](setup-cron-job.md); it gives you **visibility and a manual run-now** button over what the cron already does. ## Open it **Scheduler** in the sidebar, or `/admin/tsync_scheduler`. It is reached from the [Configuration Center](configuration-center.md) when hub mode is on. ## What you see - **Jobs** — every registered job, what it does, when it last ran and whether it's healthy. - **Runs** — the history of each run with its status (success / failed / skipped). - **Failures** — runs that errored, so you can spot a problem quickly. - **Locks** — a job runs under a lock so it never overlaps itself; you can see (and, if needed, reset) a stuck lock. - **Diagnostics** — a quick health view of the whole scheduler. ## Run a job now Each job has a **Run now** button (it's a safe POST action with a confirm). Use it to force, say, the currency refresh without waiting for the daily tick. Running it manually is recorded in **Runs** like any other run. ## Enterprise view **Scheduler → Enterprise** (`/admin/tsync_scheduler/enterprise`) shows the advanced scheduling: jobs that depend on other jobs (run in the right order), priorities, SLA limits (a job that runs too long is flagged), dry-runs, and anomaly detection (a run far slower than usual is highlighted). ## Turning a job off Every job has an **enable/disable** switch. Disabling one stops the cron from picking it up while leaving its history intact — useful when a job is misbehaving and you want the rest of the schedule to carry on rather than switching off the whole cron. Enabling and disabling both require a permission of their own, so an operator who can *run* a job cannot necessarily *silence* it. ## Rehearsing a job — dry run On **Scheduler → Enterprise**, a job can be run as a **dry run**: it goes through its real steps but is marked as a rehearsal, and — importantly — **its timing is not folded into the job's baseline**. That matters because of how anomalies are detected (below): a handful of rehearsals would otherwise teach the system that the job is slower than it really is. The result is shown immediately with the status and how long it took. ## Reading the Runs list Three outcomes, and the third is the one people misread: - **success** — it ran and finished. - **failed** — it ran and raised an error. The reason is on the run. - **skipped** — it did **not** run, and that is usually deliberate. A job is skipped when it is disabled, when its lock is still held by a previous run, or — in the Enterprise view — when a job it **depends on** did not succeed. A skipped dependency is not a failure of this job; look up the chain. ## The "Last run" column answers the question you asked Most jobs in this list are **driven**: the platform's cron calls them directly, and the Scheduler observes them. Until v11.1.6 the column showed only the last run *started from this console*, so the daily currency refresh could read **10 June** while it had in fact fetched rates that morning — and an administrator would reasonably conclude the job was dead. The column now shows the **most recent of the two** and says where it came from, so "when did this last run" gets the real answer rather than a footnote about which mechanism you should have been thinking of. Where the answer genuinely does not exist, it says so: some driven jobs record nothing anywhere, and those now read **"driven, but its runs are not recorded"**. Showing a manual run in place of an answer the console does not have is exactly what made the column misleading. ## The three tiles add up **Runs (24h)**, **OK (24h)** and **Failed (24h)** used to leave a gap: 2 805 runs, 2 649 OK, and a Failed tile that was empty — 156 runs that were neither, shown nowhere. They were never missing. *OK* counts success and warning, *Failed* counts failed and timed out, so **skipped**, **locked**, **running** and **stale** fell into neither. A skipped run is usually the overlap protection working correctly — but three numbers that do not add up cannot be told apart from a silent failure. The remainder is now counted **and broken down by status** on the same screen. ## When a lock is stuck A job holds a **lock** while it runs so it can never overlap itself. If a run is interrupted — the PHP process is killed, the server restarts mid-job — the lock can outlive it, and the job then skips every cycle because it believes a copy is still running. **Reset lock** clears it. Only do that when you are confident the job is genuinely not running any more; clearing a live lock is how you get two copies of the same job at once. Resetting is recorded against the job. ## How an anomaly is decided A run is flagged as an **anomaly** when it takes longer than the job's rolling average plus twice its standard deviation. In plain terms: markedly slower than this job normally is — not slower than some fixed limit, so a job that is legitimately slow does not cry wolf every night. An **SLA breach** is the separate, absolute check: the job declared a maximum duration and exceeded it. > The Scheduler only **observes and lets you run** the existing jobs — it doesn't rewire your cron. If a job > never runs at all, first check that your server [cron job](setup-cron-job.md) is set up. ## The "Access telemetry retention" job From v10.2.0 the list carries a new managed job: **Access telemetry retention** (`security.telemetry_prune`). It deletes access-measurement data older than 30 days. **On almost every install you will see it report "skipped", and that is correct.** Access measurement ships **switched off**, so there is nothing to delete. The job says so plainly instead of reporting "success" — a pass that did nothing because it never looked is exactly the kind of report that makes a whole list unreadable. There is nothing to configure, and if you never switch the measurement on, this job will never do anything. ## Days before a critical signal escalates Next to the log-retention control there is one more setting: **days before a critical signal escalates**, default **7**, anywhere from 1 to 365. TSync's consoles detect problems reliably; what nobody was told was that a **critical** one had been open for weeks. Past this many days, such a signal raises the *"Signal open too long"* alert in the [Notification Center](notifications.md) and appears in the **Needs attention** panel. A signal you have acknowledged does not escalate, and one that stops being raised loses its clock entirely. Set it lower if you want to hear sooner; set it higher if your team already reviews signals on a longer cycle.