Module Queue records failed automated actions involving service or domain modules. It gives an administrator a place to investigate and retry failures, but clearing an entry does not itself repair the remote hosting account or domain.
IN THIS ARTICLE
What should I check before retrying a queued module action?
- Open Utilities and Module Queue. Identify the client, service or domain, action, error and original attempt time.
- Open the related WHMCS record and confirm that the requested action is still appropriate. A cancellation, later payment or manual repair may have changed the situation.
- Check the remote panel or registrar for the actual state. A timeout can occur after an account was created, so do not assume the remote operation failed completely.
- Resolve the underlying problem, such as an unavailable API, invalid credentials, a missing package or an insufficient registrar balance.
- Use Retry for the individual action and inspect the returned result. Verify the remote result and the WHMCS record afterwards.
01 Use resolution controls carefully
Mark Resolved dismisses the queue item when the matter has already been handled or no longer requires that action. It does not execute the operation. Add an internal note explaining why the queued action was dismissed and where the actual resolution can be confirmed.
Retry All can affect many customers. Review the selected failures and their current state before using a bulk retry. A credential repair may resolve a common cause, but unrelated stale actions can still be inappropriate to repeat.
02 Understand retries
The queue does not independently keep retrying each stored item automatically. The underlying automation process may attempt its normal action again according to its own schedule and policy. Check both the queue and the source task instead of treating the queue as a separate scheduling engine.
03 When an error keeps returning
Enable module logging briefly for a controlled reproduction and retain the relevant request and response securely. Redact credentials and customer data before escalating. Include the action, timestamp, module version and remote account state so that support can distinguish a transport failure from a rejected operation.