Automation session get
automation_session_getRead one finished automation run: its verdict, the test it belonged to, the device/browser it ran on, its full desired capabilities, how long it took, and whether a video or failure snapshot exists. START HERE when the user pastes a session id or an /automation?session_id=... link and asks what happened, why it failed, or how it went. Returns verdict together with confidence: "reported" means the test itself declared the outcome and is authoritative; "inferred" means the run reported nothing and the platform guessed from how it ended — accurate most of the time but NOT a fact, so say so rather than stating it flatly. stillRunning: true means the run has not finished yet — report it as in progress, never as "no result". On a FAILED run this also returns failureAnalysis, whose shape depends on failureAnalysis.source: "recorded" (the common case — this run was already analysed automatically in the background) carries failures, one entry per failure on this run (today always one), each with failureCategory (app_bug / test_script / environment_device / timing / unknown), confidence, reasons, aiComment, target (the element this failure's lookup was searching for — value/strategy/locator plus source: "failed_command" when a WebDriver call itself failed on it, "last_find" when the test reported the failure itself and this is the last element lookup beforehand — and stepIndex naming which command; null when there was nothing to resolve), the initialVersion and latestVersion this analysis has gone through, any human/agent feedback left on it, and the effectiveVerdict — trust effectiveVerdict over failureCategory when they differ, since it already accounts for feedback. reanalysisPending: true alongside failureAnalysis means a background refresh was just triggered (a newer rule set landed since this was last analysed, or nothing was analysed yet) — the fields returned now are the best answer available immediately; re-read in about 30 seconds for the refreshed one. analysisUnavailable: {reason} instead means this run cannot be analysed at all right now (its data aged out of the grid, or was never retained) — do not re-read expecting a change; say plainly that no analysis exists for this run and why. "lazy" (an older run the background analysis never reached) carries the flatter pre-recorded shape instead: failureCategory/confidence/reasons directly, plus flakiness facts (pass rate over this test's recent runs, whether it is flaky vs a clean regression, whether it only fails on this device) and, on an element-lookup failure with a failure-time screen snapshot, screenAtFailure describing what the screen looked like when the lookup gave up. Either way this is rule-based, not a guarantee — read the reasons before repeating the category as fact, and use automation_session_feedback to correct one that is wrong. Only your own runs are readable; another user's session is indistinguishable from one that does not exist.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The run's session id — the `session_id` value from an /automation?session_id=... link, or the id shown on the run. |