Automation tools for UI testing that prove they can see the UI first

They assume the worker executing the test is always capable of seeing a UI. That is not true in practice. RDP sessions disconnect. Azure load-balanced VMs shift the desktop session. Virtual display drivers fail to register a headless monitor. The browser automation tool has no opinion about any of this because the browser runs in-process inside the test runner. Desktop UI automation runs against the OS accessibility API, and that API can silently lose the desktop out from under you. Terminator's MCP agent ships an HTTP /ready endpoint that actively probes UIAutomation, grabs the desktop root, and enumerates its children before the job dispatcher sends work. If any step fails, the worker returns 503 Service Unavailable and the orchestrator pulls it out of rotation. Source: crates/terminator-mcp-agent/src/main.rs line 793.

Healthy maps to 200 OK. Degraded maps to 206 Partial Content. Unhealthy maps to 503 Service Unavailable. The mapping lives in crates/terminator/src/health.rs line 25 inside HealthStatus::to_http_status(). Degraded is a real state in the middle: api_available is true but either the desktop cannot be accessed or the element enumeration returned zero children. That covers the common case where the UIAutomation COM object initialized fine but the display was hot-unplugged or RDP dropped the session. Browsers do not have this state because a headless browser always reports itself as having a page; for desktop automation it is the failure mode that bites the most often.

On Windows the probe runs inside tokio::task::spawn_blocking wrapped by tokio::time::timeout(Duration::from_secs(5), check_future). Five seconds is the ceiling. If CoInitializeEx hangs, UIAutomation::new_direct() hangs, or get_root_element() hangs past five seconds, the probe returns Unhealthy with error_message set to 'Health check timed out after 5 seconds - UIAutomation API may be unresponsive' and the HTTP layer returns 503. The timeout is in crates/terminator/src/platforms/windows/health.rs line 35. No dangling COM reference, no stuck readiness probe, no flaky test dispatched against a frozen UIA thread.

/health is a liveness probe: it confirms the process is alive and the HTTP stack responds. It always returns 200 if the server is up. It does not touch UIAutomation. You point Azure Load Balancer at it and probe every five seconds without interfering with in-flight tests. /ready is a readiness probe that actually exercises the accessibility stack. It is expensive (500ms to 5s on Windows), so you probe it less often: once at worker startup, once per test before dispatch, once in a Kubernetes readinessProbe initialDelaySeconds, or on demand from a diagnostics page. Both endpoints are wired in main.rs lines 792-794. Mixing them up is a common ops footgun with any UI test automation worker fleet.

The JSON payload on Windows includes: com_initialized (bool), api_available, desktop_accessible, can_enumerate_elements, check_duration_ms, desktop_child_count (integer), is_headless (bool), display_width, display_height, display_x, display_y, desktop_name, plus error_message if any step failed. The writes happen in crates/terminator/src/platforms/windows/health.rs lines 62-205. For example, if the probe succeeds but reports desktop_child_count: 0 with a display_warning of 'Desktop has no child windows', you know the worker booted UIA cleanly but the display is disconnected. That is different from api_available: false which means COM itself is broken. Two different fixes, two different alert routes, both visible in one JSON response.

Because the browser is the runtime. Chromium starts in the same process tree as Playwright, exposes a DOM over DevTools Protocol, and there is no external accessibility service between the test and the page. If Chromium starts, Playwright can query the DOM. Desktop UI automation is the opposite: the accessibility tree is produced by a separate Windows service, depends on a functioning display subsystem, and can be silently degraded by session switches, GPU driver reloads, or certain GPO-restricted hosts. The health probe exists because the gap between 'process is alive' and 'UIA can enumerate a button' is wider than any of the ranked automation tools for UI testing wants to admit.

Yes, that is one of its stated design targets. The inline comment at main.rs line 898 lists 'Pre-deployment validation, Diagnostics and troubleshooting, Kubernetes readiness probes (less frequent)'. A readinessProbe with periodSeconds: 30 and failureThreshold: 2 is reasonable. Pair it with a livenessProbe hitting /health at periodSeconds: 10. The readiness probe will flip the pod to NotReady when UIA becomes unreachable, the livenessProbe will not kill the pod unless the whole axum server dies. This is the pattern Kubernetes expects and Terminator models it directly.

The HTTP endpoint is defined cross-platform. The underlying check_automation_health() call dispatches to WindowsHealthChecker, MacOSHealthChecker, or LinuxHealthChecker depending on target_os. macOS and Linux checkers currently return Healthy with a diagnostic note that deep AX and AT-SPI checks are not yet implemented (health.rs lines 167-200). So on Windows you get real probe semantics today; on macOS you get a liveness-equivalent readiness response. That is an honest gap that most automation tools for UI testing do not even document because they never differentiated the two endpoints.

npx -y terminator-mcp-agent@latest --transport http --port 3000. Then curl -s http://localhost:3000/ready | jq .status. You will see 'ready', 'degraded', or 'not_ready'. The HTTP status code mirrors it. Pipe it into your CI pre-flight: before the pipeline dispatches a test, it curls the worker, checks the status, and skips or retries if the worker is not ready. This replaces the 'it worked on my VM' pattern with a binary signal. The shell command, the endpoint, and the response shape are all visible in main.rs line 870-886.