Asterisk taskprocessor queue reached its high-water mark

Treat the warning as a named queue event

Preserve the complete warning, timestamp, taskprocessor name, reported depth and high-water mark before restarting or reloading. Record the full Asterisk version, uptime, recent configuration or application change, call and registration rate, host CPU, memory and storage pressure, and whether the symptom affected new SIP requests, established calls, AMI or ARI consumers, queues, voicemail, device state or another subsystem.

A high-water warning proves that one named taskprocessor accumulated work to its configured threshold. It does not by itself prove CPU saturation, a deadlock, a SIP flood, a carrier fault or insufficient queue capacity. A short burst that drains and a queue that remains elevated need different investigations; retain repeated samples rather than one final zero-depth snapshot.

Capture queue depth and service time without erasing the incident

Use the installed CLI help first, then collect core show taskprocessors at short, bounded intervals. Current Asterisk source defines columns for processed tasks, current queue, maximum depth, low and high water, and lowest and highest processing time; it also supports a like filter. Keep the named row with its timestamps and the concurrent workload.

Where the installed branch exposes it, core show taskprocessor name <name> reports the current queue, maximum depth, water marks, alert, suspension and execution state. Development-mode builds may expose queued-task origins; production output may not. core ping taskprocessor <name> enqueues work and measures when it is processed, so it is an active probe with a five-second wait in current source—not proof that every task type is healthy. Use it sparingly and only under the incident owner's authorization.

Separate the producer, queue and consumer

Map the taskprocessor prefix and the activity that creates its work. PJSIP distributor queues, subscription state, Stasis messages, queue-member state, voicemail and external-control applications can have different producers and consumers. Correlate the first rising sample with signaling rate, reloads, endpoint churn, subscriptions, AMI or ARI clients, database latency and module-specific logs.

Do not assume the noisiest module is the blocker. A fast producer can outrun a healthy single consumer, a slow callback can hold one consumer, an external dependency can delay completion, or a reload can enqueue a bounded burst. Preserve one nearby healthy taskprocessor as a control and identify whether the affected queue drains when its producer becomes quiet.

Keep PJSIP admission control separate from queue ownership

Asterisk 22 documents taskprocessor_overload_trigger as the res_pjsip distributor's overload detector. Its default global mode reacts to any taskprocessor overload; pjsip_only restricts that trigger to PJSIP taskprocessors, and none disables detection. When triggered, the distributor stops accepting new requests until the overload clears. That is a PJSIP admission response to an alert, not proof that a PJSIP queue caused the alert.

The same reference says the alert clears after all alerting taskprocessors drop to their low-water level and warns that pjsip_only and none can make conditions worse. Preserve the loaded value and the exact rejected or ignored SIP request evidence. Do not disable overload detection merely to remove a warning or convert shed work into an unbounded backlog.

Do not turn water marks into performance tuning by guesswork

The documented MWI queue controls exist for heavily loaded systems, but a larger high-water mark changes alert and backlog behavior; it does not make a slow consumer faster. The low-water mark controls when an alert clears, so raising one number without a recovery model can lengthen latency, memory use and outage detection. MWI-specific queue limits are not generic settings for every taskprocessor.

Before changing any limit, retain the producer rate, drain rate, maximum depth, task service time, user-visible latency, resource headroom and supported configuration owner. First correct a demonstrated producer storm, blocked dependency, application callback, database path or module defect. If capacity engineering remains necessary, use a staged load plan and a documented rollback threshold rather than a production incident as the benchmark.

Recover one owner and prove the queue drains

Choose the least disruptive correction that matches the evidence: stop an unintended reload loop, rate-limit or repair an authorized event producer, restore a failed dependency, fix the identified application consumer, or apply a version-specific vendor correction. Coordinate any module reload or Asterisk restart because it discards volatile evidence and can affect calls; a restart that empties a queue is not a root-cause finding.

Repeat the same bounded workload and collect queue depth, maximum depth, processing time, alert transition and the affected service result through both rise and recovery. Confirm new-request behavior separately from established calls and remove temporary verbosity. No Asterisk host, taskprocessor, module, application, database, endpoint, registration, subscription, protocol exchange, load profile, resource ceiling, availability result or live call was inspected or tested for this guide.

Do not treat a channel-group threshold as a resource diagnosis

A dialplan group count can gate selected channels but does not measure taskprocessor backlog, CPU, scheduler load, database latency or provider rate limits.

Use monitoring as a timestamped signal, not a root cause

The Prometheus diagnostic checks scrape freshness, target identity, labels and query range before correlating any metric with CLI and call evidence.

Do not diagnose taskprocessor overload from a general resource graph alone

A CPU or memory chart can bound time but cannot identify the owning taskprocessor queue. The dashboard diagnostic keeps graph, collector, CLI queue evidence and call symptoms separate.