Make desktop automations reliable: wait for state, not just time

Description and use

Desktop automation becomes more reliable by waiting for actual UI states instead of fixed delays, using timeouts and safe failure handling.

Problem

Desktop automations often fail on slower or busy systems because they rely on fixed delays instead of waiting for actual UI state.

Outcome

Using state-based waits with timeouts makes desktop automations more reliable across varying system performance and UI conditions.

Workflow

• Define a deadline (current_time + timeout).
• Loop until current_time < deadline:
• Check if the expected UI element (e.g., button) is visible.
• If visible, perform the action and continue the workflow.
• If not, wait a short interval (e.g., 200 ms).
• If deadline exceeded, stop with a clear error message.
• Handle failure paths safely: stop, explain missing element, capture diagnostics, or route to recovery.
• Test both fast and slow paths, including missing elements, different window sizes, and display scales.

Evidence

Desktop automations often work perfectly on the developer’s machine, then fail on a slower computer, a busy browser, or a screen that loads in a different order.

Source

Prefer an observable signal: a button becomes visible, a dialog closes, a window appears, or expected text is present. Keep a timeout so the automation cannot wait forever.

Source

A timeout is useful only if the next step is safe. Decide what happens when the condition never appears: stop and explain what was missing, capture diagnostic context if appropriate, or route to a recovery branch.

Source

Run the workflow when the app is responsive and when it is deliberately slowed down. Also test a missing element, a changed window size, and a different display scale.

Source