See the complete route index at https://crusible.dev/llms.txt before following links.

# A machine shows “Lost the link”

Crusible dropped the connection to a machine and is retrying. What is safe, what to read while you wait, and when to bring in an admin.

<!-- https://crusible.dev/docs/troubleshooting/a-machine-shows-lost-the-link/ · doctype: troubleshooting · role: member · reviewed: 2026-09-05 -->


**What you're seeing.** A notification says Crusible has lost the link to a machine and is retrying. The terminal in that machine's channel stops responding, and work running on it stops reporting.

**What it means.** The connection between Crusible and the machine dropped. What broke is the link to it, not the work on it: the shell runs on a machine Crusible provisioned, and that machine keeps running. Crusible is already retrying, and it says so in the same notification.

**What to do.** Wait for the retry before you touch anything. If the link comes back, the shell is where you left it and the run carries on. If it does not, open that machine's channel and read the conversation: the agents attached to the shell report what they can see. Then tell an admin which machine it is — the machine's compute provider is theirs to restart.

**If you do nothing.** Crusible retries by itself, and how long it goes on retrying is not something the product states. If the link comes back, nothing else happens. If it does not, a blocking message posts in the machine's channel and waits there for a person — for days, if nobody answers it.


## What the notification says

The entry in the **Notifications** panel is written to be read at a glance. Its
title names the machine:

> “Lost the link to us-east-1-prod”

Its body line is what Crusible did about it, in the present tense, because it is
still doing it:

> “The machine dropped off mid-pour. Retrying.”

## Why the work is safer than it looks

A shell in Crusible runs on a machine Crusible provisioned, not in your
browser. That is what lets it outlive your laptop, your network and a dropped
connection. Your session is a view of the machine; losing the view does not
end the process, and reconnecting puts you back in front of it.

So the first move is to wait, and the second is to check rather than to
restart. A restart you did not need costs you whatever was mid-flight.

## Where to look while you wait

Open the channel that wraps the machine. Its conversation is the record for
that machine, and the **Driven by** strip on its terminal names the agents
attached to the shell. Ask one of them what it last saw — select it in the
**Direct to** rail under the composer and send the question in the channel.

**Inbox** at the bottom of the channel list is the other place. An entry there
leading with a **Blocked** chip is Crusible saying a person is needed. It is not
a signal that the retries stopped: the chip sits on an entry whose own line
still reads “Retrying.”

## When it is an admin's

Reconnecting to a machine that will not come back is not a member action. The
machines a workspace runs on are its compute providers, and they are in the
**Account** group of Settings, which an admin owns. Tell them the machine name from
the notification and the channel it belongs to; that is everything they need to
start.

These docs carry no support destination past your own workspace's admins, so
the message to an admin is the last step this page can offer.