FreePBX CDR report is missing a call

Define the missing evidence object

Start with one authorized call and record its timestamp and timezone, direction, source and destination, answer state, hangup result, extension or route, Asterisk uniqueid and linkedid if available. Then state what is missing: a row in FreePBX CDR Reports, a raw database record, a call-event trace, a recording link or an exported line. These are different evidence objects.

Sangoma describes CDR Reports as a view over CDR records stored in the database; it does not read a flat-file CDR backend. A blank GUI result therefore does not establish that Asterisk created no CDR, and a raw database row does not establish that the current report query, user scope or timezone will display it.

Prove the report query before changing the PBX

Reproduce the report with an explicit bounded date range, the correct FreePBX timezone, and the fewest filters needed to find the known call. Check direction, source, destination, disposition and user permissions separately. Search by the System Unique ID where available, because Sangoma's log guidance connects that identifier to the call-event breakdown and avoids relying only on a number that may have been transformed.

Preserve the query, account, result count and export before broadening it. A dashboard, browser cache, page limit, column interpretation or role restriction can hide a row that remains in the database. Do not change Asterisk logging, database tables or retention merely to make a filtered view return data.

Separate CDR creation from database storage

If the report query is sound, determine whether the expected row exists in the FreePBX CDR database and whether the report module is reading that same database and schema. Sangoma's module documentation explicitly requires database-backed CDR records. Confirm module and database health, table target, timestamps, permissions, recent errors and one known-present control call without dumping broad production data or credentials.

The Asterisk CDR diagnostic covers the engine and backend path in more depth. Keep engine creation, backend submission, database acceptance, report query and export as separate stages; restoring a GUI view is not proof that historical records were complete or billable.

Interpret unanswered and multi-leg calls with Asterisk semantics

Asterisk's CDR specification treats each CDR as a Party A and Party B relationship, not one guaranteed row per human conversation or SIP dialog. Parallel dialing, queues, transfers and conferences can create multiple linked records. Use linkedid, uniqueid and sequence with the documented scenarios instead of requiring one row whose source and destination match the original screen labels.

Asterisk 22 also distinguishes calls that never set an outgoing party from calls offered to an outgoing line. The unanswered setting controls the former, while congestion and other lifecycle settings influence disposition and finalization. Inspect the effective configuration before calling an unanswered attempt missing. Do not enable broader logging until privacy, storage and report consequences are approved.

Check dialplan controls and dispatch timing

Search supported custom dialplan and module-owned logic for intentional CDR controls. Asterisk 22 documents CDR_PROP(disable) as a per-channel control. Resetting, forking or disabling a CDR can change the record shape; on a FreePBX host, identify the owning supported include or module rather than editing generated files.

If CDR batch mode is enabled, retain its size and time thresholds, dispatch threading and shutdown behavior. A row that has not yet been dispatched is different from a rejected database write. safeshutdown can block shutdown while records are submitted, but submission still does not prove database acceptance or downstream import. Correlate the exact call and a known-good control across the same window.

Use CEL only for the question it can answer

Channel Event Logging records configured channel events such as start, end, answer, hangup, bridge entry and exit, transfers and linked-id completion. Asterisk 22 documents CEL as disabled by default and event selection as explicit. Existing CEL can help reconstruct a complex call whose CDR summary is surprising, but enabling it now cannot recreate a historical event that was never logged.

CEL has separate configuration, backend, data volume, access and retention requirements. Its event sequence is not a replacement CDR row or an automatic billing model. Review the precise investigation, selected events, storage capacity, privacy controls and rollback before enabling it on production.

Correct one owner and prove end to end

Correct only the demonstrated owner: report filter or role, database connection or schema, CDR configuration, intentional dialplan control, backend dispatch or retention process. Preserve the prior setting, approval and rollback. Do not manufacture a missing historical record from recollection when the data supports billing, compliance, emergency review or personnel decisions.

Repeat the original call type and one known-good control only where authorized. Confirm Asterisk lifecycle completion, backend and database acceptance, FreePBX query visibility and export content as separate checkpoints. No FreePBX host, module, call, channel, report, CDR, CEL event, log, database, backup, billing record or retention workflow was inspected or tested for this guide.

Return to the reporting model after recovery

After the known call becomes traceable, use the CDR Reports guide to document query, timezone, role, linked-record interpretation, export, privacy, retention and billing boundaries. Restoring one row does not validate historical completeness or downstream aggregation.