---
title: Why is support online but not answering visitors?
question: Why do visitors get only holding messages while support workers appear online?
area: support
surface: both
audience: beginner
keywords: [support not answering, stopped replying, online, heartbeat, holding message, support worker, tools unavailable, MCP disconnected, retry, waiting, cloud fallback]
related: [how-do-i-reply-to-and-manage-support-conversations, how-does-support-answer-when-my-desktop-is-closed, what-do-the-conversation-states-mean]
updated: 2026-09-14
visibility: public
---

# Why is support online but not answering visitors?

First check whether the conversation contains an actual agent or human answer. An automatic acknowledgement such as "An agent is looking at this now" is not a reply to the visitor's question.

The desktop's online signal confirms that the app is reporting its presence. It does not prove the worker can access its support tools or deliver an answer. A worker can remain open after losing that connection. In that state it may draft a response in its terminal while no reply reaches the conversation.

## Check the conversation and worker

1. Open the project's **chats** tab and the affected conversation. Compare the last visitor message with the last substantive reply.
2. Read the conversation state. **Waiting** can mean the automatic attempts were exhausted and the conversation was parked for the team.
3. Open the associated worker's terminal from the worker row. Record connection errors, missing support tools or sign-in problems with the time and installed app version.
4. If an answer exists in the transcript but not on the visitor's side, investigate [widget delivery](why-cant-my-visitor-see-replies.md) instead.

Updating the help library cannot repair a disconnected worker. Repeatedly asking the same worker to answer may reuse the same failed connection. Restoring the connection and returning a parked conversation to the agent are separate recovery steps.

## Why did the cloud not answer instead?

The cloud normally leaves answering to an available desktop. If that desktop appears available but its agents cannot reply, cloud answers may not take over either. The cloud does not automatically pick up conversations parked in **Waiting**; closing or reopening the desktop is not proof that those conversations were retried.

Once the worker problem is resolved, an operator can choose **take over** and answer directly. To ask the agent to handle it instead, choose **take over**, then **release to agent** on the intended conversation. The release control appears while a human owns the conversation. It requests a customer-visible reply, so check the thread and ownership first.

## How do I know it worked?

A substantive reply reaches both the operator transcript and the visitor's widget. A connected worker or another holding message alone does not establish recovery.