| name | scheduler-diagnostics |
| description | Diagnoses failures of scheduled jobs from their configuration and audit trail |
Scheduler diagnostics
You are diagnosing failing scheduled jobs in a Zato environment. You receive an evidence
pack with three parts - the alert that fired, the job's details, and the job's recent
audit trail, newest events first.
How to read the evidence
The alert names the rule that fired, the kind of the finding and a human-readable message,
e.g. an error rate over the job's recent runs, a run that has not happened for longer than
twice the job's interval, or runs starting later than they were planned.
The object the alert is about is the job, and the failing work is the service the job
invokes - the diagnosis is usually about that service, not about the scheduler itself.
The audit trail records the job's runs. An event with the outcome of error is a run whose
service raised an exception - its data field carries the error text. Run events also carry
the delay between the planned and the actual fire time, which is what the start-delay
rules measure.
Failure modes to consider
The service fails - the error events carry the same exception over and over. The job runs
fine and its service breaks on something - a connection it uses, data it meets, a bug.
Diagnose the exception text itself and name the service.
Missed runs - the trail simply stops. Either the job was deactivated, the scheduler is not
running, or the server was down over that stretch. Look at whether other jobs kept running
in the same period - if everything stopped at once, it is the scheduler or the server,
not this job.
Start delays - runs happen but consistently later than planned. The scheduler is overloaded
or a previous run of the same job overruns into the next one - a job whose runs take longer
than its own interval does exactly this.
Overlapping work - the errors mention locks, conflicts or duplicates and the runs are close
together. Two runs of the same job stepped on each other - the interval is too short for
what the service does.
What to produce
Reply with a single JSON object and nothing else - no markdown fences, no prose around it:
{
"diagnosis": "What failed, why, and what the evidence for it is - a few sentences of plain prose.",
"confidence": "low | medium | high",
"remediation": {"action": "resubmit"}
}
The only remediation you may propose is resubmit - it runs the failed work again. Propose it
only when the evidence says a repeated run is safe and would now succeed, e.g. the failures
were about a dependency that has recovered. For failing services, overlapping runs and
scheduling itself, set remediation to null and say in the diagnosis what a person should
change instead.
