Define the missing boundary for one queued call
Start with one authorized call and record timestamp and timezone, queue name, caller-channel unique ID, member interface, expected event and the report or workflow that appears wrong. Prove that the dialplan actually invoked the intended Queue() application and preserve its QUEUESTATUS separately from queue-log evidence. Hearing music or seeing a CDR does not prove queue admission or a queue-log write.
Classify the symptom precisely: no queue-log target, no ENTERQUEUE, an absent offer or CONNECT, a missing terminal event, a custom event without the expected identity, lines assigned to another call, a rotated interval, or a downstream report that omits source rows. Each boundary has a different owner.
Resolve the effective logger destination
Asterisk documents the queue log in the configured log directory, with /var/log/asterisk/queue_log as the usual default. Resolve the running astlogdir, queue_log enablement, queue_log_name, queue_log_to_file and realtime behavior from the effective configuration rather than assuming the packaged sample or a familiar path is active.
File output and a realtime queue-log backend are separate destinations. When realtime logging exists, queue_log_to_file controls whether Asterisk also writes the file. A missing file can therefore coexist with accepted realtime records, while a present file does not prove a realtime consumer received them. Record target ownership, permissions, free space and current error evidence before changing either path.
Interpret event identity and parameters exactly
A queue-log row begins with timestamp, the queued caller channel's unique ID or a documented special value, queue name, member channel, event type and event-specific parameters. Follow that tuple through ENTERQUEUE, member offers, CONNECT, completion, transfer, abandonment or queue exit. Do not correlate rows merely because they are adjacent or share a caller number.
Event parameters are not interchangeable. CONNECT includes hold time, the bridged member-channel unique ID and ring time, while abandonment and exit events carry position and wait values. A queue-log connection is not proof of two-way audio, and a missing transfer record does not by itself prove that no endpoint-side transfer occurred.
Keep native and custom events distinguishable
The dialplan QueueLog() application and AMI QueueLog action can add custom entries with an explicitly supplied queue, unique ID, interface or agent, event name and message. Confirm the producing dialplan branch or AMI transaction and every supplied identity before using a custom row to extend native queue history.
A syntactically accepted custom entry does not prove that the named queue, channel or member existed, that the call reached Queue, or that later reporting understands the event. Namespace and document custom event names, preserve producer version, and keep application-level milestones separate from Asterisk-generated offer and connection events.
Separate production, rotation, storage and import
Treat event production, logger routing, file or realtime acceptance, durable retention, rotation, collection, parsing and report query as independent checkpoints. Preserve a known-present control row on both sides of the missing interval. Compare timestamps with the documented clock basis; the realtime GMT option changes timestamp handling for that backend and does not repair an unrelated timezone conversion downstream.
Inspect rotated names and the collector cursor before concluding that Asterisk skipped an event. A logger reload, process restart, external rotation or importer restart can create a boundary even when the call path is unchanged. Protect extracts because caller and agent identities may be present, and do not rewrite or delete source records while attribution remains disputed.
Correct one owner and replay the evidence chain
Correct only the first demonstrated divergence: wrong queue path, disabled logging, unexpected file-versus-realtime policy, log directory or name, permissions or capacity, rotation handling, custom-event identity, importer cursor, parser schema, timezone conversion or report filter. Preserve the prior configuration, privacy and retention approval, capacity impact and rollback trigger.
Replay one authorized queued call and a known-good control. Verify Queue admission, expected native sequence, any custom event, selected destination, durable record, import and final query separately. Confirm the logger and rotation state after the test. This workflow is derived from first-party documentation and was not reproduced on a customer or laboratory PBX.
Recover the queue event chain before judging priority
A missing or mismatched queue-log row blocks a reliable priority comparison. Rebuild the event chain, then use the FreePBX priority workflow.
Do not replace queue history with a status snapshot
The AMI queue-snapshot diagnostic keeps point-in-time state separate from queue-log and channel history.
Keep QueueReset separate from queue-log history
The AMI queue reload or reset diagnostic verifies counters, retained log records and reporting views independently.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk queue logs ↗
- Asterisk logging configuration ↗
- Asterisk main configuration file ↗
- Asterisk 22 Queue application ↗
- Asterisk 22 QueueLog application ↗
- Certified Asterisk 22.8 QueueLog AMI action ↗
- Asterisk QUEUE_VARIABLES function ↗
- Sangoma Queue Priorities user guide ↗
- Sangoma Queue Priorities module overview ↗
- FreePBX Queue Priorities release/17.0 repository ↗
- FreePBX Queue Priorities release/17.0 metadata ↗
- FreePBX Queue Priorities release/17.0 dialplan source ↗
- Asterisk standard channel variable QUEUE_PRIO ↗
- Asterisk Queue application ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
- ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.