Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.41

track-time-first-attempt

Globalset by the Hub

Whether to record the time of the first delivery attempt
in the configuration this is a linetrack-time-first-attempt falseinside the block Global
The delay between receipt and the first action

The line makes the engine record when it first tried to deliver a message. Any outcome counts as an attempt: delivery, a bounce, a temporary error from the recipient domain or the queue. The default is false.

🔴 This is not an event record but switching on a count. While the line is off, the value does not exist: it cannot be recovered from accounting or from the log. All you can do retroactively is turn it on and wait for new messages.

It opens up in two ways at once. The value appears in accounting records of types d, b and t — which means it also has to be listed in record-fields (with the * set it gets in by itself). And it also becomes the pmta_smtp_first_attempt_seconds metric if <prometheus-listener> is configured.

What this value actually means. Not delivery time, but the delay between receiving a message and the first action taken on it. It is a direct measure of whether the node keeps up with its queue: if it grows, messages are waiting, and it grows earlier than deliverability deteriorates.

The vendor names the price: a noticeable impact on disk access, especially when many attempts end in temporary errors. That is, it costs the most exactly when it is most useful.

The main trap is turning it on without listing the field. With an explicit list in record-fields the value goes nowhere, and the line only costs disk access. With the * set the field gets in by itself.
What the Hub does. It writes true — at the root of both templates, since Aug 30, 2026: without the line the message time would be a single value, with it the time splits into waiting in the queue, the delivery itself and retries.

To the fields of deliveries and bounces the Hub explicitly adds timeFirstAttempt, totalSecondsQueued and numRetries — they are not part of the asterisk. From them telemetry calculates delivery time without the queue, and “Accounting stats” — where the time goes inside delivery. The price is disk access, and it is higher precisely on a problem node: the manual mentions increased disk I/O with a large number of temporary failures.

Recommended values

The decision is simple, but it has a price:

Value When
false (default) always, while the value is not needed
true the receive-to-send delay is needed in accounting or in metrics

Next to it are two lines that work only when this one is on: time-first-attempt-hires-timestamp — milliseconds in the accounting record, and time-first-attempt-domains-file — a per-receiver breakdown of the metric.

The false default, the list of record types where the value appears and the warning about disk impact with frequent temporary errors come from the manual (§ 3.3.1.41, § 11.22). Interpreting the value as a measure of keeping up with the queue is ours.
Example configuration
# the value will appear in accounting and in the metric — but only from this moment on
track-time-first-attempt truetime-first-attempt-hires-timestamp true

<prometheus-listener 0/0:9090>
</prometheus-listener>
The second line does not work without the first. The block is needed only for the metric: the value will get into accounting without it.
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 ends2 mistakes▶

Turning it on retroactively to look at the past

our experience

What it costsThe value was not stored anywhere and cannot be computed from what exists. Data will appear only for messages received after the edit.
How to spot itAfter it is turned on, the field is filled in new records and empty in old ones.
How to do it rightTurn it on in advance — together with the rest of the accounting set, not when it is needed.

Turning it on on a node that is already disk-bound

§ 11.22

What it costsThe vendor mentions the impact on disk access, especially with frequent temporary errors. On an overloaded node the line will add load exactly when the node is already in trouble.
How to spot itAfter it was turned on, disk wait time grew on a node with a large share of 4xx.
How to do it rightTurn it on in advance on a healthy node, not on a problematic one during an investigation.
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
track-time-first-attempt <boolean>
Values
yes | no | true | false
Default
false § 3.3.1.41
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line is written at the root of the file, in the Global section, and applies to all of the node’s messages. The count cannot be enabled selectively — by receiver or stream; only the metric can be broken down by receiver, and only via time-first-attempt-domains-file.
How to check on the node
Check in accounting — whether the field has a value:
head -1 "$(ls -t /var/log/pmta/acct-*.csv | head -1)" | tr ',' '\n' | grep -i first
The column appears only when the line is on and the field is in the set. In JSON format the same is checked on any record. The metric — with a request to the Prometheus listener port.
In the Hub
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Troubleshoot deliverability · Collect telemetry