Knowledge base

Three short histories for each queue

critical

individual queue page
The node kept these records all along — you just have to take them

The page of a single queue in the web monitor. It has three ring buffers, and together they are the most useful thing in the observation chapter.

Recipient events — the last fifty: what actually happened to this queue’s recent messages. A sequence of outcomes, not a summary number.

Queue errors — the last ten: recent refusal reasons. They show exactly what the receiving server replies, not which category it ended up in.

Mode changes — the last ten transitions between backoff and normal. This is the backoff mode history directly, not derived by polling.

The third buffer is the main value. It means the node kept a record all this time: there is no need to ask “what mode is the queue in” over and over and piece episodes together from the difference between answers.

The main trap is taking a ring buffer for a log. Fifty events and ten each of errors and transitions are the latest, not all. On an active queue fifty events fit into minutes, and yesterday’s picture will not survive in them. The page answers the question “what is happening now” and does not answer “what was going on Thursday” at all — that is what accounting is for.
What the Hub does. It reconstructs the history of mode changes by polling: it asks which queues are in backoff mode, compares with the previous measurement and opens or closes an episode.

⚠️ But the node keeps this history itself — in this very third buffer. Our way is worse in two respects: polling is blind between measurements and misses a short trip into backoff mode entirely; and our transition time is the measurement time, not the event time.

The Hub does not read recipient events and queue errors from here either: the same outcomes reach it through the accounting stream — together with the receiver’s reply text, which it stores next to the category.

Recommended values

Three buffers and the question each answers:

Buffer Depth Question
recipient events 50 what happened to recent messages
queue errors 10 what exactly the receiver replies
mode changes 10 when the queue went into backoff mode

Depth is counted in events, not in time. On an active queue that is minutes, on a dormant one weeks. The same page covers completely different spans for different queues.

Take accounting for history, this page for “now”.

The depth analysis and the “now versus history” advice are ours. From the manual here are the composition of the three buffers and their sizes.
Example configuration
# the same from the command line
pmta show queues --mode-events gmail.com/mta-news-1pmta show queues --errors gmail.com/mta-news-1
The highlighted line adds the third buffer to the output — the mode change history, the very one that otherwise has to be reconstructed by polling.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Looking for yesterday's picture in a ring buffer

§ 5.4

What it costsThe buffers keep the latest events, not all of them. On an active queue fifty events fit into minutes — yesterday is not in them and cannot be.
How to spot itThe page has only recent events, while the case under investigation is a week old.
How to do it rightUse accounting: it exists precisely for history. The page answers the question of what is happening now.

Reconstructing mode history by polling

§ 5.4

What it costsThe node keeps it itself, in the third buffer. Polling is blind between measurements: a short spell in backoff mode will be lost entirely, and the transition time will turn out to be the time of the measurement.
How to spot itThe reconstructed history has fewer episodes than the receiving server had refusals, and the episode boundaries are multiples of the polling period.
How to do it rightAsk for the history directly — with the command’s option or on this page.

Comparing queue errors with accounting categories

§ 5.4

What it costsHere are the receiving server’s words, in accounting the category a pattern assigned to them. These are different levels, and a mismatch between them is not an error.
How to spot itThe error text on the page resembles none of the categories in the report.
How to do it rightRead one as the cause in the receiving server’s words, the other as its classification.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
How to check on the node
The same three can be obtained without the web monitor:
pmta show queues --mode-events --errors gmail.com/mta-news-1
One command with two options returns everything the page shows: recipient events come by default, errors and transitions are added with options.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Tune the pace for a provider · Untangle a stuck queue
Priority
critical