Define one custom event contract before writing
Choose a stable custom Event name, define what business transition produces it and document the meaning and order of any Message values. Keep custom names distinct from the built-in queue-log event types documented for queue lifecycle, member changes, answers, transfers and exits; a familiar-looking label does not acquire native Asterisk semantics.
Treat every supplied field as data, not proof. A caller Uniqueid, queue name and member Interface can help a later reader correlate records, but a custom row does not establish that a queue, caller or member existed or that the described transition occurred.
Send all published QueueLog fields explicitly
The branch-22 and branch-23 AMI pages say QueueLog adds a custom entry and expose Queue, Event, Uniqueid, Interface, Message and optional ActionID. Only ActionID has a published field description. The pages publish no validation rules, omitted-field defaults, delimiter escaping, length limits or response-to-storage guarantee.
Supply an exact value for every business field, preserve the raw AMI request and response and use a unique ActionID only for the AMI transaction. Do not reuse that identifier as a caller, queue or log-row identity unless the application has explicitly designed and verified such a convention.
Map the request to the documented row shape
The official queue-log guide documents pipe-delimited fields in this order: timestamp, typically the caller channel unique ID, queue name, queue member channel, event type and event parameters. It also says the identity field can be REALTIME or NONE. Compare an observed custom row field by field rather than assuming how every AMI string was normalized or escaped.
The separately documented dialplan QueueLog() application accepts queue name, unique ID, agent, event and optional additional information. AMI and dialplan entry points can therefore produce similarly shaped custom records, but their initiating transaction, caller context and error evidence remain different.
Separate action success from durable and visible evidence
An AMI success response establishes only what the responding node accepted. The reviewed action pages document no corresponding row event or terminal storage notification. Prove the custom row independently in the active queue-log destination, then preserve node identity, file identity, timestamp, byte range and exact serialized fields.
A row in the active file does not prove it survived rotation, reached an alternate backend, was ingested once by a parser or appeared in a report. Conversely, a missing report row does not by itself prove the AMI action or file write failed. Locate the first boundary where evidence diverges.
Keep custom markers separate from call outcomes
The queue-log guide gives built-in events distinct parameter contracts: for example, CONNECT, completion, abandon, transfer, timeout and ring-no-answer rows describe different points in queue handling. A custom marker near one of those rows is supplementary application evidence, not a replacement for the native event, CDR, CEL, channel, bridge, recording or media record.
Use the same node clock and a bounded time window, and retain exact Uniqueid and channel identities where available. Do not reconstruct causality from adjacency alone: concurrent callers, reused labels, buffering, clock skew and downstream sorting can place unrelated records together.
Test negative paths without polluting production reports
In an approved nonproduction window, send one namespaced custom event with non-sensitive values. Capture the response, locate the serialized row, rotate or ingest only if the test plan permits it, and confirm each downstream stage independently. Exercise wrong node, denied manager account, invalid or unexpected field values, duplicate requests, parser restart, active-file rollover and report-cache delay.
Avoid production event names and personal data in tests. No PBX, module, manager account, session, queue, caller, member, log file, database, parser, report, endpoint, packet, audio or live call was inspected or tested; documentation does not establish availability, compatibility, accepted values, escaping, persistence, delivery, deduplication, report visibility or call outcome.
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.