critical
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.
⚠️ 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.
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 same from the command line pmta show queues --mode-events gmail.com/mta-news-1pmta show queues --errors gmail.com/mta-news-1
what people get wrong and how it ends3 mistakes▶
§ 5.4
§ 5.4
§ 5.4
4 relations
Refusal at the greetingOne of the refusals that end up in the second buffer — queue errors. § 5.8
Details of one queueThe same page, returned by a request — together with the histories. § 5.4
QueuesA neighboring catalog entry. § 5.4Messages in the queueThe screen that shows the same thing to a human. inferenceQueue state together with event historyThe same view for a single queue on the monitor screen — with the histories. § 5.4Recipient eventsThe screen where the mechanism is visible. § 11.17
pmta show queues --mode-events --errors gmail.com/mta-news-1
3 articles
◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.◇The watchdog that restarts the engineKeeps an eye on the engine and brings it back up after a crash by itself, sending a crash report to the postmaster address.◇How the policy for a receiver is assembledSettings are assembled from the most general pattern to the most precise; the order of blocks in the file means nothing.