Freeze one request and expected row
Preserve the responding node and release, loaded app_queue module, manager account permissions, transport continuity, raw request and response, ActionID, Queue, Event, Uniqueid, Interface, Message, expected queue-log destination and observation window. Redact credentials and personal data.
Write the expected row contract before searching: which supplied value should identify the caller or synthetic workflow, which queue and member labels are expected, what event namespace is custom and how message parameters should be interpreted. Do not silently replace the request with values from a dashboard.
Prove the action reached the intended node
Match the AMI response to the request by ActionID and session framing. A response from a different cluster member, an interrupted session or a parser that paired the wrong response can create a false success narrative. The generated action pages describe no storage acknowledgement beyond the action response.
Confirm the exact node and its queue-log destination before checking a shared filesystem or reporting database. A healthy queue on one node and an empty log on another are not contradictory evidence.
Compare the active row without inventing validation rules
Inspect the active queue-log destination for the bounded time window and compare timestamp, unique-ID field, queue, interface or member field, event and parameters separately. The official row format permits REALTIME or NONE in the identity field, while the AMI pages publish no field validation, omission, escaping or length rules. Preserve the raw bytes when punctuation or delimiters are disputed.
If the row is absent, distinguish rejection, accepted request with no observed write, unexpected destination, disabled or changed logging, file permissions and observation timing. Do not claim which cause applies without node evidence.
Follow rotation, backend and parser boundaries
Identify the active file and any rotated files by inode or equivalent identity and timestamps rather than filename alone. If the deployment also sends queue records to another backend, treat that as a separate output; a populated file and empty database can coexist.
Then verify parser checkpoint, input byte range, accepted schema, deduplication key, rejected-row handling and output transaction. A parser can skip a custom event it does not recognize, split unexpected parameters, ingest twice after restart or lag behind an intact file.
Verify report meaning against native queue events
Confirm the report maps the custom event namespace and parameter contract intentionally. Do not let a custom event named like CONNECT, ABANDON or another documented native type inherit a built-in KPI meaning. Compare any claimed caller outcome with native queue-log events, CDR, CEL and channel or bridge evidence.
If the custom marker exists but the intended business event did not occur, repair the producer condition rather than the logging path. If the business event occurred but the row is wrong, repair the exact request field or serialization boundary first.
Repair one boundary and rerun a disposable case
Correct only the proved node selection, manager permission, field construction, event namespace, log destination, rotation handling, parser rule, deduplication key or report mapping. Repeat one nonproduction event and retain the AMI response, active row, downstream record and report result as separate evidence.
No PBX, module, manager account, session, queue, caller, member, log file, database, parser, report, endpoint, packet, audio or live call was inspected or tested. Availability, compatibility, accepted values, escaping, persistence, delivery, deduplication, report accuracy and call outcome remain deployment specific.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.