$ guides / postfix / postfix-queue-message-age ▌

Operations Guides

Postfix queue message age: the delivery latency queue depth cannot show

A queue of 10 messages whose oldest is 3 hours old is worse than 10,000 messages aged 5 seconds. Depth tells you volume. Age tells you latency. They answer different questions, and conflating them leads to missed incidents.

Postfix exposes no built-in “oldest message age” metric. The showq daemon reports per-message arrival times to postqueue, but no aggregate age, no percentile, no histogram. Most monitoring setups track queue depth as a count and stop there. A flat depth line looks healthy. But if messages enter and leave the queue at the same rate, depth stays constant even when every message takes 4 hours to deliver instead of 4 seconds.

The signal that catches this is message age. It distinguishes “the queue is draining” from “the queue is draining fast enough.” This article covers how to measure message age in Postfix, what the thresholds mean, and what to investigate when age climbs while depth looks normal.

What this means

Queue depth is a snapshot count. Message age is the elapsed time since each message entered the queue. A queue holding 5,000 messages that turns over completely every 30 seconds is healthy. A queue holding 5,000 messages that has not moved a single one in 2 hours is an incident. Depth alone cannot distinguish these states.

This divergence appears in a specific failure pattern: queue file count steady, but oldest file age increasing. The active queue may be full of messages to one slow destination, consuming delivery slots through Postfix’s fair queueing scheduler. New mail enters the active queue as old mail times out, so the count stays roughly constant. But each message sits in that queue for hours, aging without triggering a depth alert.

Depth-based alerts fire when the queue fills past a threshold. Age-based alerts fire when messages are not being delivered fast enough, regardless of count. The two are complementary.

Postfix’s deferred queue compounds the problem through exponential backoff. When a delivery fails temporarily, the message moves to deferred and the queue manager schedules a retry. The retry interval grows with each failure, bounded by maximal_backoff_time (default 4000 seconds, roughly 1.1 hours). A message that keeps failing may not be retried for over an hour. The queue depth counts this message as one entry whether it has been there for 5 seconds or 5 hours.

Postfix eventually gives up after maximal_queue_lifetime (default 5 days, 432000 seconds). Until then, the message sits in deferred, aging. Depth looks fine. Age does not.

flowchart TD
    A["Queue depth looks normal"] --> B{"Oldest message age?"}
    B -->|"< 30 min"| C["Healthy: delivery flowing"]
    B -->|"30 min - 1 hr"| D["Investigate: delivery impedance"]
    B -->|"> 1 hr"| E["Escalate: active degradation"]
    B -->|"> 4 hr"| F["Incident: severe delivery failure"]
    D --> G["Check deferral reasons in logs"]
    E --> G
    G --> H{"Single destination dominating?"}
    H -->|"Yes"| I["Slow destination monopolizing slots"]
    H -->|"No"| J["Check DNS, filter, reputation"]

Common causes

Cause	What it looks like	First thing to check
Slow destination monopolization	One domain dominates deferred entries; active queue full but not saturated by volume; depth steady, age rising	`grep 'status=deferred' /var/log/mail.log` grouped by destination domain
DNS resolver degradation	All destinations affected equally; “Host not found” or “Name service error” in logs; delivery rate near zero	`dig` from the MTA host to a known-good domain
Content filter backpressure	Incoming queue growing while active queue is small; filter process memory high or unresponsive	Test filter port connectivity directly
Exponential backoff accumulation	Deferred queue contains many messages with retry timers far in the future; age high but depth moderate	`qshape deferred` to see age distribution
IP reputation degradation	Specific major destinations returning 4xx codes; deferral rate elevated for one or few providers	Check sender reputation externally

Quick checks

# See per-message arrival timestamps in human-readable form
postqueue -p | head -30

# Age of oldest message across all queues, in minutes (requires Postfix 3.1+ and jq)
postqueue -j | jq -rs 'map(.arrival_time) | min | ((now - .) / 60 | floor)'

# Age distribution across deferred queue, geometric buckets
qshape deferred | head -20

# Age distribution with linear buckets (Postfix 2.2+)
qshape -l deferred | head -20

# Per-message delivery timing from the delays= log field
grep 'delays=' /var/log/mail.log | tail -20

# Check queue lifetime and backoff ceiling
postconf -h maximal_queue_lifetime maximal_backoff_time

# Current deferred queue depth for context
find /var/spool/postfix/deferred -type f | wc -l

The delays=a/b/c/d field in delivery log lines breaks down as follows: a is time before the queue manager, b is time spent in the queue, c is connection setup time, and d is message transmission time. The b component is the queue residence time for that delivery attempt. A rising b across recent log lines means messages are spending longer in the queue before delivery.

A critical caveat for deferred messages: the queue manager warps the modification time (mtime) of deferred queue files into the future to implement exponential backoff cool-off. Reading mtime via stat on deferred files gives you the next scheduled retry time, not the original arrival time. The arrival time is stored inside the queue file itself and is correctly reported by postqueue -p, postqueue -j, and qshape. Do not compute age from deferred file mtimes directly.

How to diagnose it

Establish whether age is actually elevated. Run qshape deferred and look at the distribution across age buckets. Default buckets are geometric: 0-5 minutes, 5-10, 10-20, 20-40, 40-80, 80-160, 160-320, 320-640, 640-1280, and 1280+ minutes. A healthy deferred queue has most messages in the first few buckets. Messages accumulating in the 320-minute and higher buckets indicate aged backlog.

Determine scope. Is age elevated across all destinations or concentrated on specific domains? Parse deferred entries from logs:

# Top deferred destination domains in the last hour
grep 'status=deferred' /var/log/mail.log | \
  awk -F'to=<' '{print $2}' | cut -d@ -f2 | \
  sort | uniq -c | sort -rn | head -10

Check delivery velocity. Compare injection rate to delivery rate. If injection continues but delivery has dropped, the queue is accumulating faster than it drains:

# Delivered messages in last 5 minutes (GNU date; same-day comparison)
awk -v t="$(date -d '5 minutes ago' '+%H:%M:%S')" '$3 >= t' /var/log/mail.log | \
  grep -c 'status=sent'
# Deferred messages in last 5 minutes
awk -v t="$(date -d '5 minutes ago' '+%H:%M:%S')" '$3 >= t' /var/log/mail.log | \
  grep -c 'status=deferred'

These compare the syslog time field ($3, in HH:MM:SS format) against a cutoff. They break across midnight; use journalctl --since on systemd hosts for boundary-safe filtering.

Identify the constraint. If one destination dominates deferrals, check connectivity and reputation for that domain. If all destinations are affected, check DNS resolver health and content filter responsiveness first.
Distinguish new-message slowness from old-message stagnation. Messages that have failed multiple times have retry timers hours in the future. They contribute to age but will not be retried soon. Use the age distribution from qshape rather than just the average to tell whether new messages are slow or old messages are aging without retry.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Oldest message age	Direct measure of worst-case delivery latency	Oldest message older than 1 hour
Average queue age	Indicates systemic delivery impedance	Average above 30 minutes for transactional mail
Deferred queue age distribution	Reveals whether old messages are accumulating in backoff	Significant mass in buckets above 320 minutes
Delivery rate vs injection rate	Shows whether the queue is growing or stable	Delivery rate below 80% of injection sustained
Per-destination deferral rate	Identifies which destination is consuming delivery capacity	One domain accounting for majority of deferrals
`delays=` log field, `b` component	Per-message queue residence time at delivery	Median `b` value trending upward over time
Active queue utilization	Shows whether queue manager can schedule new deliveries	Active queue above 80% of `qmgr_message_active_limit`

Fixes

Slow destination monopolization

When one destination consumes delivery slots through fair queueing, reduce concurrency for that transport. Note that smtp_destination_concurrency_limit applies globally to the smtp transport; for per-destination throttling, use a transport map entry.

# Reduce per-destination concurrency for the smtp transport (applies on reload)
postconf -e 'smtp_destination_concurrency_limit=5'
postfix reload

For targeted relief, hold mail to the problem domain, fix the underlying issue, then release:

# CAUTION: verify the grep pattern matches only intended messages before holding
<!-- TODO: verify: grep on raw queue files may miss messages due to Postfix's binary record format. Prefer postqueue -j piped through jq for reliable recipient filtering. -->
find /var/spool/postfix/deferred -type f -exec grep -l '@problem.example' {} \; | \
  xargs -r postsuper -h

Do not flush the entire deferred queue. The Postfix QSHAPE documentation explicitly warns that flushing undeliverable mail frequently degrades delivery performance for all other mail. Selective requeueing in small batches is safer than postsuper -r ALL.

DNS resolver failure

Test resolution directly from the MTA:

# Test against configured resolver
dig @$(awk '/nameserver/ {print $2; exit}' /etc/resolv.conf) gmail.com MX

If the local resolver is failing, add a fallback resolver to /etc/resolv.conf and reload Postfix. DNS problems affect all destinations equally, which distinguishes them from single-destination issues.

Content filter backpressure

If the content filter or Milter is slow or unresponsive, mail queues before filtering. Test the filter port directly:

# Test filter connectivity (example: Amavis on port 10024)
nc -zv localhost 10024

In an emergency, temporarily bypass the filter to restore mail flow:

# CAUTION: accepts unfiltered mail. Investigate root cause before doing this.
postconf -e 'content_filter='
postfix reload

Exponential backoff accumulation

Old deferred messages with retry timers hours away will not retry on their own. Selectively requeue messages that may now succeed after you have fixed the underlying cause:

# Requeue specific messages (safer than bulk flush)
postsuper -r <queue_id>

Accept that some messages will age until maximal_queue_lifetime expires them. Focus on preventing new messages from entering the same backoff cycle.

Prevention

Track message age alongside depth. Depth catches volume spikes. Age catches latency degradation. Both are needed. If your monitoring only tracks queue file counts, you have a blind spot for slow-delivery incidents where depth stays flat.

Baseline your normal age distribution. Run qshape deferred during healthy operation at different times of day. Know what your normal age distribution looks like so you can recognize when it shifts.

Monitor deferral reasons proactively. The reason codes in deferred log lines tell you why messages are aging. Track the top deferral reasons over time so a new reason appearing is an early signal rather than a surprise.

Know your queue lifetime parameters. Document maximal_queue_lifetime and maximal_backoff_time for your environment. These define how long messages age before expiration and how long between retries.

Filter by delay class. Bulk and campaign mail legitimately increases queue age. Transactional mail does not. Separate monitoring thresholds by mail class to avoid false alarms from expected bulk sends while still catching real degradation in transactional delivery.

How Netdata helps

Netdata surfaces queue metrics that help correlate depth changes with delivery patterns:

Queue depth metrics for active, deferred, incoming, maildrop, and hold queues let you distinguish a steady-state queue from one that is turning over slowly.
Anomaly detection on queue depth trends flags subtle shifts in drainage rate that raw thresholds miss, including the case where depth stays flat while delivery velocity drops.
Correlation across signals lets you overlay deferred queue growth with DNS resolver latency, content filter response times, and per-destination delivery rates to identify the constraint quickly.
Historical baselines built from high-resolution data make it easier to distinguish a legitimate campaign spike from an actual delivery impedance pattern.