Skip to main content

​
Overview

Cyberdesk checks whether Cyberdriver is reachable at run startup and after an in-run Cyberdriver request exhausts its normal retries. These checks distinguish a sustained machine-side outage from a transient request failure. Automatic machine state quarantine is currently paused while reachability classification is tuned. A failed run-owned check does not change the desktop’s connection status, availability, pool memberships, or Cyberdriver routing target. A genuine Cyberdriver WebSocket disconnect can still update connection state through the normal connection lifecycle. Cyberdesk confirms the outage with a lightweight display-dimensions request.
  • Mid-run confirmation first waits 2 seconds so Cyberdriver can finish any abandoned request that timed out on the client.
  • It then makes up to three dimensions attempts.
  • Each attempt uses a 10-second request timeout.
  • After a failed attempt, Cyberdesk waits 2 seconds, then 4 seconds, before the next attempt. The first successful response means the machine is reachable and stops the check.
  • Any unsuccessful response counts as a failed attempt, including HTTP 4xx.
If all three attempts fail, Cyberdesk:
  • Ends the affected run with an error status and repair instructions.
  • Leaves the desktop’s status, availability, pool memberships, and routing target unchanged.
  • Immediately sends a downed_machines webhook when Downed machine alerts is enabled for that desktop.
The alert setting controls only webhook and Slack delivery. Reachability confirmation and normal run error handling still apply when alerts are disabled.

​
Run Error

The affected run explains what Cyberdesk detected:
Cyberdriver became unreachable on this machine after 3 display checks. Repair or restart Cyberdriver on the machine, then verify that it reconnects.
Remaining runs in the same chain or session are cancelled through the normal failure flow.

​
Slack And Webhook Alerts

When Downed machine alerts is enabled, confirmed run-time detection immediately publishes the existing downed_machines event. Its reason identifies the Cyberdriver outage. The payload still contains the organization’s full current set of monitored downed machines. The recurring monitor is a fallback, not a second notification. Cyberdesk records the alert transition before publishing, so a monitor check one second later sees the machine as already down and does not send a duplicate event. If immediate delivery fails, Cyberdesk releases the alert claim so the next monitor check can retry it. See Downed Machines Webhook to connect alerts to Slack or another destination.

​
Respond To A Confirmed Failure

  1. Open the affected Windows desktop and repair or restart Cyberdriver.
  2. Verify that the desktop reconnects in Dashboard -> Desktops.
  3. Confirm that basic desktop actions work.
Cyberdesk also does not send a recovery webhook. A successful run-start dimensions check clears the internal alert state, allowing a later outage to notify you again.

​
Scheduled Monitoring

The recurring downed-machines monitor continues to check opted-in desktops even when no run is active. It uses the same maximum of three attempts, 10-second probe timeouts, and 2s/4s spacing between failures. The first successful dimensions response stops the check. Scheduled monitoring sends alerts but does not change desktop state or remove desktops from pools.