What Do ReadyQueueWasFull and DueTimeWasReached Mean?
These messages appear when mail is being accepted but not leaving the server. Neither is an error. Each one describes a message that was returned to the Scheduled Queue to wait, rather than delivered.
When KumoMTA moves a message from the Scheduled Queue to the Ready Queue, it first checks whether the Ready Queue has room (governed by max_ready). If it is full, the message is delayed by a small random interval, returned to the Scheduled Queue, and a Delayed log record is written with a reason such as ReadyQueueWasFull. DueTimeWasReached means the message's next-attempt time arrived and it is being evaluated again.
A steady stream of these records means the Ready Queue cannot drain. Mail is arriving faster than it can egress.
The three usual causes
- All sources for the pool are suspended. Spam complaints or block responses trigger Traffic Shaping Automation to suspend sources, so there is nothing to send from. See Why Are All Sources Suspended?
- The destination is throttling you. The mailbox provider is limiting connections or rate based on your reputation, so the Ready Queue drains slowly. Review your shaping for that destination.
max_readyis too small for the destination's sustained rate, so messages oscillate between the Scheduled and Ready Queues. See Why Is KumoMTA Using So Much Memory?
How to triage
# Where is volume sitting, and which destinations are limited?
$ kcli queue-summary --by-volume
# Is anything suspended?
$ kcli top
Then check the metrics for the affected queues: delayed_due_to_ready_queue_full, delayed_due_to_message_rate_throttle, and ready_full tell you whether you are looking at a full Ready Queue, a throttle, or a suspension. Read the transient-failure log records for the destination to see the provider's actual responses.