Most run problems fit one of the situations below. For each, start with the symptom, then the likely cause, then what to check. The last line says what the Monitoring Agent can do about it today.
Likely cause. The run has been accepted but has not been dispatched yet. The dispatcher may be at its concurrency limit, the task's contention profile may have no free slot because another run holds the lock, or the dispatcher poll interval has not come round yet.
What to check. The Monitor page's queue and dispatcher dashboards, the contention profile attached to the task and which run is holding it, and whether other tasks on the same profile are running longer than expected.
What the agent can do. At Observe it reports that the run is waiting, and why, based on the queue and lock state. It does not release a lock or start the run.
Likely cause. Polysync called the platform and the call did not return a run to watch. The platform refused the request, usually because of a credential, a permission, an invalid definition or a network problem, and returned its message instead of a run id.
What to check. The platform's message on the run, the platform's credentials and their expiry, and whether the pipeline, job or item still exists under the name the task uses. Nothing was started on the platform, so there is no platform run to inspect.
What the agent can do. It groups the failure with earlier identical messages and names the class: credential, permission, configuration or connectivity. It cannot retry, and a retry would fail the same way until the cause is fixed.
Likely cause. The run started and the platform has not reported a terminal state. The platform's job may be stuck, waiting on a lock or a resource, or the polling call may be failing while the platform run continues. Polysync keeps the run in Running while it waits, and a polling timeout eventually closes it with the last state it saw.
What to check. The platform's own console for the external run id: is the run still alive there, and where is it? Historical duration for the same task on the Monitor page tells you how unusual this is.
What the agent can do. It reports the run as unusually long, and points at the external run id. It does not cancel anything.
Likely cause. The dependency did not become satisfied: the parent failed, is still running, or ended in a state the dependency does not accept. A misconfigured dependency, an upside-down arrow or a cycle in the graph has the same effect.
What to check. The dependency graph on the task, the parent run's final state, and the Monitor page's dependency overlay, which shows which edges are satisfied.
What the agent can do. It explains which parent held the child back and with what status. It does not trigger the child.
Likely cause. The retry settings apply to certain failures only, and the run may have ended in a state the task does not retry, such as a cancelled run or a failure recorded before the run was dispatched. The maximum number of attempts may already be spent, or the retry chain may have ended.
What to check. The task's retry settings, the run's attempt history on the Monitor page, and whether the failure was recorded by the platform or by Polysync before dispatch.
What the agent can do. It reports the failure class and whether a retry is safe for that class, but it does not retry. Its own retries arrive with level 2 and above.
Likely cause. Two triggers overlapped: a schedule and a manual run, two schedules, or a retry that started while the first attempt was still alive on the platform. A retry after a timeout can also duplicate work when the platform run had actually succeeded.
What to check. The task's schedules and their recent firings, the run history for the task, and whether two TaskRun records share one external run id or hold two different ones. The second case means the platform really ran it twice.
What the agent can do. It flags the duplicate and groups both runs so the pattern is visible. Stopping it requires a schedule or contention change by a person.
Likely cause. The platform returned a state Polysync does not map, usually after a platform change or a partial response. Polysync keeps the raw status and does not guess.
What to check. The platform's console for the external run id, which holds the authoritative state, and whether other runs on the same platform show the same behaviour.
What the agent can do. It reports the raw status without classifying it. If you see this repeatedly, tell support: it usually means a provider mapping needs updating.
On Monitor, Agent Insights, open the insight for a failed run and choose Ask the agent. The panel opens with that run as context, so you can ask what it was waiting on, whether it has failed the same way before, or which dependency blocked it. The assistant reads only the data described on Agent data and privacy and shows what it used. It can also propose a rule to stop the same failure recurring; a proposal waits for your approval before anything is written.