Troubleshooting / Article

Troubleshoot an automation that is not replying

Find whether the message stopped before SiloBox, during generation, or while delivering the reply.

Before you start

Choose one failed example and note the time, automation, connected account, and customer conversation. Open the correct workspace. Use a recognizable new test message so you can distinguish it from older messages. Avoid sending several tests at once: configured delays can collect messages, and an uncertain delivery may already have started a reply flow.

A missing reply can happen at different stages. First establish whether SiloBox received the message, then whether it generated an answer, and finally whether Manychat delivered it. Changing the prompt will not repair a request that never reached SiloBox.

Find the stage that failed

Open Chats and locate the test conversation. If no matching message appears, check the Manychat entry point, published request flow, connected account, and Automation ID. Confirm that the request flow points to the intended automation rather than another test automation.
Open the automation and confirm it is enabled and uses the expected prompt and connection. Check that the prompt has a published version and that API access is allowed. Saving a draft does not update the published instructions.
Inspect the conversation's AI status. Human handoff or manual intervention may have paused replies. Use Resume AI only when your team is ready to return the conversation to the assistant; a deliberate pause is not a delivery error.
Review any configured processing delay. With time since the last message, each new message restarts the timer. Allow that interval to pass without adding more test messages before concluding the run is stuck.
If the conversation shows a generation failure, read the error and check the provider credential, model access, and relevant usage or billing message. Test the prompt with the intended credential to separate generation from channel delivery.
If an answer was generated but did not reach the customer, open Message details on the failed turn and inspect Manychat delivery details. Check response field destinations and types, the published Responses flow, the connected account, and any reported channel restriction.

Check the result

After making one targeted correction, send a fresh test and follow it from the incoming message to the actual reply in the channel. Confirm it went to the intended contact and that the content matches the published prompt. A successful prompt test or a received conversation alone is not an end-to-end success.

If the issue remains

Record the failing stage, time, automation ID, request ID if shown, and the displayed error or provider codes. Share those with support without API keys or private customer content. For uncertain delivery, inspect Manychat before retrying to avoid duplicate replies. Do not reset the conversation merely as a first diagnostic step; preserve the evidence that explains the failure.

Check media and channel-specific pauses

If text works but a file does not, check the saved automation's Process audio messages and Process images and PDFs settings. A disabled type is passed as a plain-text link, not processed as media. With processing enabled, the file URL must be the entire message; inspect the displayed media error if the file cannot be fetched or processed. File processing can add credits and time.

Pause controls belong to a conversation and channel. Check the exact contact and channel rather than assuming a resume in one chat resumes every channel. Resetting preserves the pause state and contact facts, and cancels queued replies; it is not a general repair for missing replies. When routing multiple automations, verify the Automation ID actually supplied by the flow.