scheduler-diagnostics

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.