I have set up call center reporting on FreePBX more times than I can count. The pattern is always the same: someone installs FreePBX, gets the queues running, and then asks "where are my reports?"
The answer is uncomfortable. FreePBX's built-in reporting is not designed for call center operations. It is designed for a PBX that happens to have queues.
That distinction matters more than most teams realize until they are three months in and cannot answer basic questions like "what is our average wait time by hour?"
My take: FreePBX is the best open-source PBX management interface available. But treating its reporting modules as call center analytics is like using a spreadsheet as a CRM - it technically works, and it will technically hold you back.
What FreePBX Actually Gives You (Honest Assessment)
Before you spend time evaluating external tools, understand exactly what ships with FreePBX. Some of it is better than people think. Most of it is worse.
CDR Reports Module (Free, Built-in)
This is what most people discover first. It queries Asterisk's cdr table and presents it through a web interface.
What it does well:
- —Call history lookup by date range, extension, or DID
- —CSV export for offline analysis
- —Basic call duration statistics
What it cannot do:
- —Show queue-specific metrics (calls are logged by channel, not by queue context)
- —Track agent state transitions (login, pause, available, wrap-up)
- —Calculate SLA compliance
- —Display anything in real time
Here is the SQL that FreePBX CDR runs under the hood:
-- This is essentially what FreePBX CDR module queries
SELECT calldate, src, dst, duration, billsec, disposition, channel, dstchannel
FROM cdr
WHERE calldate BETWEEN '2026-04-01' AND '2026-04-02'
ORDER BY calldate DESC;Notice what is missing: no queue_log join, no agent identification, no wait time calculation. The CDR module operates on a completely separate data source from your queue operations.
My take: CDR reports are fine for billing reconciliation and basic "did this call happen" lookups. They are not call center reporting. If someone tells you CDR reports cover your analytics needs, they have not run a call center.
Queue Reports (Commercial Module - $149)
Sangoma sells a Queue Reports module that many teams buy expecting it to solve their reporting problems.
What it adds over CDR:
- —Queue-level call counts (answered, abandoned, timed out)
- —Agent login duration tracking
- —Basic wait time averages
What still does not work:
- —No real-time dashboard (data refreshes on page load, not live)
- —Wait time averages hide the distribution - you cannot see that 80% of calls wait 10 seconds while 20% wait 4 minutes
- —No correlation between agent performance and queue outcomes
- —No heatmaps or pattern visualization
- —Cannot compare performance across time periods
The $149 is a one-time purchase, which is reasonable. But the capability gap between what it provides and what a 20-agent call center actually needs is significant.
UCP (User Control Panel)
UCP is agent-facing. It shows personal call history, voicemail, and presence. It is not a reporting tool and I will not pretend it is one.
The FreePBX Reporting Gap (With Numbers)
Here is a practical example. A 15-agent FreePBX call center needs to answer these questions daily:
| Question | FreePBX CDR | Queue Reports ($149) | External Analytics |
|---|---|---|---|
| How many calls did we handle today? | Partial (no queue filter) | Yes | Yes |
| What is our SLA compliance right now? | No | No (no real-time) | Yes |
| Which agent has the highest AHT? | No | Partial (login time only) | Yes |
| What hour has the most abandoned calls? | No | No (no hourly breakdown) | Yes |
| Are we staffed correctly for tomorrow? | No | No | Yes |
| Which trunk is at capacity? | No | No | Yes |
| How does this week compare to last week? | Manual CSV export | No | Yes |
6 out of 7 questions require an external tool. The one question FreePBX partially answers (call count) still requires manual filtering.
Setting Up Real Reporting on FreePBX
Step 1: Enable Queue Logging (Critical - Most Skip This)
FreePBX queue logging is not fully enabled by default. Without it, no external tool can help you.
In FreePBX Admin, go to Applications > Queues, then for each queue:
- —
Under Advanced tab:
- —Event When Called: Yes
- —Event Membership: Yes
- —Queue Logging: Yes (this is the one people miss)
- —
Under Timing & Agent Options:
- —Wrap-Up Time: Set to your actual wrap-up target (default 0 means no tracking)
- —Member Delay: 0 (unless you need announcement before connecting)
Then verify logging is working:
# Check that queue_log is being written
tail -20 /var/log/asterisk/queue_log
# You should see entries like:
# 1774000000|1774000001|support|CONNECT|15|SIP/200|12
# 1774000012|NONE|support|ADDMEMBER|SIP/201If queue_log is empty, check your Asterisk configuration:
; /etc/asterisk/logger.conf
; Make sure queue_log is enabled
[logfiles]
queue_log => queue_log# After changes:
fwconsole restart
# Or if you want to avoid dropping calls:
asterisk -rx "logger reload"My take: I estimate 40% of FreePBX call centers have incomplete queue logging. They discover this 3 months in when someone asks "why is the data missing?" Fix it now.
Step 2: Configure AMI for External Tools
Every external monitoring tool connects through Asterisk Manager Interface (AMI). FreePBX manages this, but you need to create a dedicated user.
Go to Settings > Asterisk Manager Users in FreePBX, or edit directly:
; /etc/asterisk/manager.conf (managed by FreePBX - use GUI when possible)
[monitoring]
secret = generate_a_32_char_password_here
deny = 0.0.0.0/0.0.0.0
permit = 10.0.0.0/255.255.255.0 ; Your monitoring server subnet
read = system,call,log,agent,reporting
write = system,call,agent,reporting
writetimeout = 5000Security note: never use permit = 0.0.0.0/0.0.0.0 in production. Restrict to your monitoring server's IP or subnet. AMI with open access is how PBX systems get compromised.
# Test AMI connection from your monitoring server
telnet freepbx-server 5038
# Then type:
Action: Login
Username: monitoring
Secret: your_password
# You should get: Response: Success
# Then test queue data:
Action: QueueStatus
Queue: your_queue_nameStep 3: Set Up Database Access for Historical Reporting
For historical analytics, external tools need access to the CDR and queue_log databases. FreePBX uses MySQL/MariaDB:
# Create a read-only database user for analytics
mysql -u root -p
CREATE USER 'analytics'@'monitoring-server-ip' IDENTIFIED BY 'secure_password';
GRANT SELECT ON asteriskcdrdb.cdr TO 'analytics'@'monitoring-server-ip';
GRANT SELECT ON asteriskcdrdb.cel TO 'analytics'@'monitoring-server-ip';
FLUSH PRIVILEGES;If your external tool uses the queue_log file directly (some do), configure log rotation carefully:
# /etc/logrotate.d/asterisk-queue-log
/var/log/asterisk/queue_log {
monthly
rotate 12
compress
delaycompress
missingok
notifempty
copytruncate # Important: don't move the file, copy and truncate
}My take: copytruncate is essential. If logrotate moves the file, Asterisk keeps writing to the old file descriptor until restart, and you lose data. I have seen this cause "missing data" reports that took weeks to diagnose.
FreePBX Reporting Tools Compared (Honest Rankings)
1. Astervis - Best for Teams Who Want Results, Not Projects
Astervis is purpose-built for Asterisk-based PBX systems including FreePBX.
Setup on FreePBX:
# On your FreePBX server or a separate machine (recommended)
curl -fsSL https://api.astervis.io/api/releases/install.sh | bash
# Add your FreePBX server in the dashboard
# Queues auto-discovered within 60 secondsWhat makes it different for FreePBX:
- —Auto-discovers FreePBX queue configuration (no manual queue mapping)
- —30+ charts including heatmaps, agent performance trends, trunk analytics
- —Real-time dashboards that update sub-second via AMI events
- —Operator management with KPIs, leaderboards, and shift scheduling
- —CRM integration (Bitrix24, AmoCRM)
- —Self-hosted - your data stays on your network
Pricing: From $119/month, unlimited operators. 14-day free trial.
Where it fits: Teams running FreePBX as a call center (5+ agents) who need immediate visibility without a setup project.
2. Grafana + Custom Stack - Best for DevOps Teams
If you have a DevOps engineer and want full customization:
- —Install Grafana + PostgreSQL/TimescaleDB
- —Write a parser for
/var/log/asterisk/queue_log - —Create AMI event listener for real-time data
- —Build dashboards from scratch
Realistic timeline: 40-80 hours for a production-quality setup. Then ongoing maintenance.
# Example: basic queue_log parser to PostgreSQL
# This is the EASY part. The hard part is real-time AMI event processing.
awk -F'|' '{print $1","$2","$3","$4","$5","$6}' /var/log/asterisk/queue_log \
| psql -c "COPY queue_events FROM STDIN WITH CSV"My take: I respect teams that build their own analytics. But I have watched three Grafana-on-FreePBX projects start enthusiastically and get abandoned within 6 months when the engineer who built it leaves or gets pulled to other work. The initial build is 20% of the cost - maintenance is 80%.
Tired of guessing what's happening in your queues?
Astervis gives you 30+ real-time charts, operator KPIs, and CRM integration for your Asterisk PBX. Self-hosted. Install in 5 minutes. From $119/mo flat — unlimited operators.
3. QueueMetrics - Legacy Option
QueueMetrics has been around since 2004 and has deep Asterisk integration. But it requires Java/Tomcat on your FreePBX server.
# QueueMetrics installation on FreePBX
yum install java-11-openjdk tomcat # Java + Tomcat on your PBX server
# Download and deploy WAR file
# Configure database, AMI, queue_log path...
# Total setup: 2-4 hours if everything goes rightThe FreePBX-specific problem: Running Tomcat alongside FreePBX on the same server competes for resources. Java's memory footprint (typically 512MB-1GB) on a system that is also processing real-time voice is not ideal. Production FreePBX servers should dedicate resources to call processing.
See our detailed QueueMetrics comparison for pricing and migration analysis.
4. Asternic Stats - Budget Option
Asternic is simpler than QueueMetrics and uses PHP instead of Java:
- —Reads
queue_logdirectly - —Basic web dashboard (pre-2010 UI aesthetic)
- —Lower resource footprint than QueueMetrics
The honest take: Asternic works for basic queue statistics. If you need "how many calls per queue per day" and nothing else, it is adequate. It does not do real-time monitoring, agent performance tracking, or anything resembling modern analytics.
See our Asternic comparison for full details.
FreePBX-Specific Reporting Queries
If you are building custom reports or need to verify your analytics tool is calculating correctly, here are the SQL queries that actually work on FreePBX's database:
Agent Performance from queue_log
-- Agent call counts and average handle time (FreePBX queue_log table)
SELECT
agent,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS calls_answered,
COUNT(CASE WHEN event = 'RINGNOANSWER' THEN 1 END) AS calls_missed,
ROUND(AVG(CASE WHEN event = 'COMPLETECALLER' OR event = 'COMPLETEAGENT'
THEN CAST(data2 AS UNSIGNED) END)) AS avg_talk_seconds,
ROUND(AVG(CASE WHEN event = 'COMPLETECALLER' OR event = 'COMPLETEAGENT'
THEN CAST(data1 AS UNSIGNED) END)) AS avg_hold_seconds
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE())
AND agent != 'NONE'
GROUP BY agent
ORDER BY calls_answered DESC;Hourly Abandon Rate
-- Abandon rate by hour (identifies understaffing windows)
SELECT
HOUR(FROM_UNIXTIME(time)) AS hour,
COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) AS abandoned,
COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END) AS total,
ROUND(100.0 * COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) /
NULLIF(COUNT(CASE WHEN event IN ('CONNECT','ABANDON') THEN 1 END), 0), 1) AS abandon_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE() - INTERVAL 7 DAY)
AND queuename = 'your_queue'
GROUP BY HOUR(FROM_UNIXTIME(time))
ORDER BY hour;SLA Compliance (80/30)
-- SLA: percentage of calls answered within 30 seconds
SELECT
DATE(FROM_UNIXTIME(time)) AS day,
COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 30 THEN 1 END) AS within_sla,
COUNT(CASE WHEN event = 'CONNECT' THEN 1 END) AS total_answered,
ROUND(100.0 * COUNT(CASE WHEN event = 'CONNECT' AND CAST(data1 AS UNSIGNED) <= 30 THEN 1 END) /
NULLIF(COUNT(CASE WHEN event = 'CONNECT' THEN 1 END), 0), 1) AS sla_pct
FROM queue_log
WHERE time > UNIX_TIMESTAMP(CURDATE() - INTERVAL 30 DAY)
AND queuename = 'support'
GROUP BY DATE(FROM_UNIXTIME(time))
ORDER BY day DESC;Trunk Utilization (FreePBX CDR)
-- Concurrent call peaks by trunk (capacity planning)
SELECT
DATE(calldate) AS day,
HOUR(calldate) AS hour,
channel,
COUNT(*) AS calls,
MAX(duration) AS max_duration
FROM cdr
WHERE calldate > DATE_SUB(NOW(), INTERVAL 7 DAY)
AND channel LIKE 'PJSIP/trunk%'
GROUP BY DATE(calldate), HOUR(calldate), channel
ORDER BY calls DESC
LIMIT 20;Common FreePBX Reporting Mistakes
1. Trusting CDR Duration as Talk Time
CDR duration includes ring time. CDR billsec is closer to talk time but still includes IVR navigation. Neither represents actual agent-customer conversation time.
For accurate talk time, use queue_log CONNECT/COMPLETE events with the hold time (data1) and talk time (data2) fields.
2. Not Separating Queue Types
A single SLA target across sales, support, and VIP queues is meaningless. Configure separate queues in FreePBX and track them independently:
; queues_additional.conf (FreePBX manages this, but understand the structure)
[sales](!)
servicelevel=20 ; 20-second SLA for sales
strategy=rrmemory
[support](!)
servicelevel=30 ; 30-second SLA for support
strategy=leastrecent
[vip](!)
servicelevel=15 ; 15-second SLA for VIP
strategy=linear ; Always ring best agent first3. Ignoring After-Call Work
FreePBX default wrapuptime=0 means agents immediately receive the next call after hanging up. This causes:
- —Inaccurate AHT (wrap-up work is done during the next call)
- —Agent burnout (no processing time between calls)
- —Incorrect capacity calculations
Set appropriate wrap-up time:
; In FreePBX: Applications > Queues > Queue Settings
wrapuptime=30 ; 30 seconds between callsRead more about preventing agent burnout through proper workload management.
4. Running Reports During Peak Hours
Analytical queries against the CDR database compete with call processing. Schedule heavy reports for off-peak hours, or better yet, replicate data to a separate analytics database.
What to Set Up This Week
If you are running FreePBX with queues and have no analytics beyond CDR reports, here is your action plan:
Day 1: Enable queue logging on all queues (Step 1 above). Verify queue_log is being written.
Day 2: Configure AMI access for external monitoring (Step 2). Test the connection.
Day 3: Install an analytics tool. Try Astervis free for 14 days - setup takes 10 minutes on FreePBX.
Day 4-5: Configure SLA thresholds per queue. Set wrapuptime. Review initial data.
The difference between "we think our call center is performing well" and "we know our SLA is 78% with a 14% abandon rate at 2 PM" is the difference between hope and data.
FreePBX handles the calls. Analytics tells you whether it is handling them well.
For more on optimizing your FreePBX call center, see our complete Asterisk monitoring guide, CDR reporting deep dive, and real-time queue monitoring setup.
Stop guessing. Start monitoring.
See your Asterisk call center's real performance — queue wait times, agent activity, trunk usage, and 30+ charts. Self-hosted on your server. Install in 5 minutes. No credit card required.
From $119/mo flat. Unlimited operators. 14-day free trial.