Demo
Demo

Knowledge base

PMTA knowledge base›Block <domain>›Directive§ 3.3.10.7

max-events-recorded

<domain>

How many recent events are kept in memory for this domain
in the configuration this is a linemax-events-recorded 10inside the block <domain>
The engine’s short memory for errors

How many recent events the engine remembers about a recipient domain. The manual clarifies: currently only errors are recorded, no other events get into this list.

This is not a log. The manual says directly: events are not written to a file, they are kept in memory. Everything else follows from that — a service restart wipes them, grep over the log will not find them, and they can be seen only on a running engine: show domains with the –errors option, show topdomains –errors or the queue page in the web monitor.

Why it is needed. The “last error” column in the domain list is the fastest answer to the question “what is wrong with this recipient.” There is no need to search accounting and match times: the engine already keeps the latest refusals next to the queue they belong to.

The default is 10. The web monitor shows exactly as many on the queue page — “the last 10 errors of the queue.”

The main trap. Memory is spent on each domain, not once per node. The manual specifically warns that recording events may affect memory usage: on a fleet sending to hundreds of recipients, a depth of a hundred events turns into tens of thousands of entries. Raise the value selectively — in the block of the recipient you are investigating, not in the general one.
What the Hub does. It neither writes nor collects it. When polling a node it takes the name, the number of recipients, the volume and the connections from the queue and domain lists (for queues, also the paused flag), and does not read the last error column. So these events are not in the Hub’s monitoring either: they have to be looked at on the node itself.

There is no reason to touch the default of ten events: it costs nothing and is usually enough for an investigation.

Recommended values

There is no need to change the default. The last ten errors answer the question “what is happening now,” while history is accounting and the log, not the engine’s memory.

Raise it selectively and temporarily. Investigating one recipient: set 50 in its block, take a look, set it back. In the general block the same number will be multiplied by the number of domains in the queue.

Zero makes sense only where memory is more expensive than investigation — for example, on a small node with a very broad recipient list.

The advice to raise it selectively is ours. From the manual here come the 10 default, the fact that events live in memory and are not written to the log, that only errors are recorded, and the warning about memory usage.
Example configuration
# we leave the general block as is and raise it only where we are investigating
<domain *>
    max-events-recorded 10
</domain>

<domain problem-mailbox.example>
    max-events-recorded 50</domain>
The manual’s example sets 3; here, on the contrary, it shows why to raise it: the depth is needed for one recipient, not for all at once — memory is spent on each domain separately.
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 these events in the log

§ 3.3.10.7

What it costsThe manual says directly: they are not written to a file but kept in memory. Searching the log gives nothing, and the investigation goes astray — while the answer is visible with one command.
How to spot itThere is nothing about the domain in the log, while the console shows its last error.
How to do it rightAsk the engine with a command using the –errors option. For history, use accounting: there events survive a restart.

Raising the depth in the general block

§ 3.3.10.7

What it costsMemory is spent on each domain. A hundred events in the <domain *> block on a fleet with hundreds of recipients means tens of thousands of entries in memory, and the manual specifically warns about such usage.
How to spot itThe engine’s memory usage grew after an edit that “should not have changed anything.”
How to do it rightKeep the default in the general block, and raise the depth in a specific recipient’s block and set it back after the investigation.

Expecting per-recipient events here

our experience

What it costsOnly queue errors are recorded. Deliveries, bounces and deferred messages for specific addresses belong to the neighboring directive track-recipient-events, and it is off by default.
How to spot itThe console shows that the queue is erroring, but it is unclear for which addresses and with what response.
How to do it rightEnable track-recipient-events — it keeps the last fifty per-recipient events.
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.
Reference data
Syntax
max-events-recorded <integer>
Values
an integer number of events; the default is 10
Default
10 § 3.3.10.7
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file — which is why the “ten in general, fifty for this one” technique works. It is picked up by pmta reload, no restart needed, but events already accumulated are lost on a service restart.
⇄

Related directives

3 relations

Works together with

track-recipient-events<domain>The other half of the same thing: this one remembers queue errors, that one events for specific recipients. § 3.3.10.15

Affects

max-memory-usage-percentGlobalEvents are kept in memory, so a large depth raises exactly the value the safety valve watches — noticeably on a fleet with hundreds of recipients. § 3.3.10.7

Where you can see it

Per-receiver summaryThe command that shows these events — with the –errors option. § 3.3.10.7

How to check on the node
Events are viewed on a running engine — they are not in the configuration, and not in the log either:
pmta show domains --errors problem-mailbox.example
pmta show topdomains --errors
The first command prints the latest errors for one domain, the second for the busiest ones. An empty error list means there were none since the service started, not that there were none at all: history lives in accounting, not here.
◇

What else to read

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.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability
Neighboring settings of the block <domain>:disabled-source-ip-notifybackoff-notifytrack-recipient-eventsdisable-acct-recordsdkim-signAll 135 directives of the block →