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; 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 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 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 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.