A program manager supervises an hourly agentic workflow that syncs supplier inventory via API and opens issues on mismatches. Leadership needs early detection of stalled, failed, or degraded runs without reading code. Which monitoring practice best tracks agentic workflow run health?
Select an answer to reveal the explanation.
Short Explanation
You don’t need to peek under the hood to know the delivery truck is late. Run history plus alerts gives you a dashboard with flashing lights, and telemetry tells you fast whether jobs stalled or failed.
Full Explanation
The correct practice is right because Actions run history gives a code-free timeline of every hourly execution with per-step status, duration, and logs, while alerts for failed or long-running jobs provide early detection of stalled, failed, or degraded runs without inspecting definitions. Monitoring supplier API latency, uptime, and rate limits is sound for diagnosing external causes, but it fails on coverage because a healthy vendor endpoint does not prove the workflow started, completed, or transformed data correctly, so internal stalls would go unnoticed. Reviewing dependency updates, audit logs, and secret rotations is sound for governance, but it fails on signal because it measures security posture and change history rather than execution health and gives no timely warning when a run misses schedule. Tracking mismatch issue counts, triage, and resolution times is sound for effectiveness, but it fails as a proxy because low output can mean clean inventory or a broken workflow, delaying recognition of failures. An exam caveat is to separate execution telemetry from external, security, and outcome telemetry when the prompt emphasizes run health without reading code. A practical check is to open the Actions tab, filter to the hourly sync workflow, compare success rates and durations, inspect one failed step log, and verify notifications for failure and excessive runtime are enabled.