Skip to main content

Overview

The downed_machines webhook tells your system when one or more important machines appear to need attention. Most teams route this event directly into Slack so operators see machine issues where they already work. Cyberdesk only monitors machines that you explicitly opt in. On a desktop’s detail page, enable Downed machine alerts to include that machine in the monitor.
Machines are not monitored by default. This avoids alerts for desktops that are intentionally offline or only used occasionally.

Send Machine Alerts To Slack

The fastest way to use machine alerts is with Cyberdesk’s existing Slack integration. You do not need to host your own webhook receiver unless you want custom routing logic outside Slack.
1

Create a machine-alert Slack endpoint

Go to Dashboard -> Webhooks -> Endpoints, click + Add Endpoint, then open the destination dropdown in the top right. Choose Send downed machine alerts to Slack.
2

Connect your workspace and channel

Click Connect to Slack. Slack will ask you to choose the workspace and channel that should receive machine alerts. Approve the connection, and you’ll return to Cyberdesk.
3

Review the selected event

The connector subscribes to the downed_machines event and includes a default Slack transformation that formats machine alerts into a structured Slack message.
4

Create the endpoint

Click Create. That’s it: newly downed opted-in machines will now post to your selected Slack channel.
You can use the default Slack message as-is. If your team wants different wording, routing context, or Slack Block Kit layout, edit the endpoint’s transformation code before creating it or any time later.
The machine-alert Slack connector includes a default Svix transformation similar to this. You only need to edit it if you want to customize the final Slack message:
For screenshots and more detail on the Slack setup flow, see the full Slack integration guide. For more on editing and testing transform code, see Webhook Transformations.

When It Fires

Cyberdesk can detect an opted-in downed machine in two ways:
  • Immediately during a run: If Cyberdriver becomes inaccessible at startup or during execution, Cyberdesk confirms the failure and publishes the event without waiting for the recurring monitor. Run-time detection currently leaves the machine’s connection state, availability, pool memberships, and routing target unchanged.
  • Recurring monitoring: Cyberdesk checks opted-in machines on a schedule even when they are not running automation.
For a connected machine, Cyberdesk requests display dimensions once. A successful response immediately qualifies the machine as up. After a failed request, Cyberdesk retries for a maximum of three total attempts. Each attempt uses a 10-second request timeout, and the pauses between failed attempts escalate from 2 seconds to 4 seconds (with a trailing 6-second delay reserved if the attempt count grows). Any unsuccessful response, including HTTP 4xx, counts as a failed attempt. When confirmation happens immediately after a run-owned Cyberdriver failure, Cyberdesk also waits 2 seconds before the first dimensions probe so Cyberdriver can finish abandoned work from the timed-out request. A monitored machine appears down when either:
  • Its Cyberdesk status is not connected.
  • Its status is connected, but Cyberdesk cannot complete a lightweight display dimensions probe after retries.
The webhook fires only when a new opted-in machine enters the down set. The payload still includes the full array of machines that currently appear down for the organization, so your alert can include context about any machines that were already down. Immediate run detection and recurring monitoring use the same atomic alert-state transition. If the recurring monitor runs immediately after a run-time alert, it sees the machine as already down and does not send a duplicate. If immediate delivery fails, the monitor can retry the alert on its next run. Cyberdesk does not send a separate recovery webhook when a machine comes back online. For run-time confirmation details and operator recovery steps, see Cyberdriver Reachability Checks.

Enable Monitoring For A Machine

  1. Go to Dashboard -> Desktops.
  2. Enable alerts from the Alerts checkbox in the desktops table, or open a desktop and enable Downed machine alerts in the Machine Status card.
  3. In Dashboard -> Webhooks, make sure your Slack endpoint or webhook endpoint subscribes to downed_machines.

Payload

Verify And Handle The Event

Use event_id for idempotency, then fan out to your alerting system. Because Cyberdesk only sends this event when a newly downed machine is found, your receiver usually does not need to dedupe repeated deliveries beyond Svix retry handling.
Svix may retry deliveries when your endpoint fails or times out. Always verify signatures and treat event_id or the svix-id header as idempotency keys.