If you're running an Asterisk-based call center, your queues are the heartbeat of your operation. Every unanswered call, every long wait, every idle agent costs you money. Yet most Asterisk administrators fly blind — they have no real-time visibility into what's happening in their queues right now.
This guide shows you every method available to monitor Asterisk queues in real-time, from native CLI commands to AMI events to purpose-built analytics platforms. By the end, you'll know exactly which approach fits your team and how to implement it today.
Why Real-Time Queue Monitoring Matters
Before diving into the how, let's quantify the why.
A call center without real-time monitoring is reactive by definition. You discover problems after they've already cost you:
- —Abandoned calls: Industry average is 5-8%. Without real-time alerts, abandonment spikes go unnoticed until end-of-day reports.
- —SLA breaches: If your target is 80% of calls answered within 20 seconds, you need to know the moment you're falling behind — not tomorrow morning.
- —Agent utilization imbalance: One agent drowning while three sit idle. Without a live dashboard, supervisors can't redistribute load in real-time.
- —Trunk saturation: When all your SIP trunks are busy, incoming callers get busy signals. Real-time trunk monitoring prevents this.
The math is simple: a call center handling 500 calls/day that reduces abandonment by 2% saves 10 calls daily. At even $50 average value per call, that's $500/day or $130,000/year — just from real-time monitoring.
Method 1: Asterisk CLI Commands
The simplest starting point. Asterisk includes built-in CLI commands for queue inspection.
queue show
The most commonly used command:
asterisk -rx "queue show"Output:
support has 3 calls (max unlimited) in 'rrmemory' strategy (18s holdtime, 145s talktime), W:0, C:47, A:12, SL:78.3%, SL2:65.2% within 60s
Members:
SIP/1001 (ringinuse disabled) (dynamic) (Not in use) has taken 15 calls (last was 342 secs ago)
SIP/1002 (ringinuse disabled) (dynamic) (In use) has taken 18 calls (last was 12 secs ago)
SIP/1003 (ringinuse disabled) (dynamic) (Paused) has taken 14 calls (last was 890 secs ago)
Callers:
1. SIP/trunk-00000a1b (wait: 0:18, prio: 0)
2. SIP/trunk-00000a1c (wait: 0:09, prio: 0)
3. SIP/trunk-00000a1d (wait: 0:03, prio: 0)
Key fields:
- —W (Weight), C (Completed calls), A (Abandoned calls)
- —SL (Service Level percentage — calls answered within target time)
- —Member states: Not in use, In use, Paused, Unavailable, Ringing, Busy
- —Caller wait times in real-time
queue show [queue_name]
For a specific queue:
asterisk -rx "queue show sales"Limitations of CLI Commands
- —No persistence: Data resets when Asterisk restarts
- —No historical comparison: You see now, but can't compare to yesterday
- —No alerting: You must manually check — no push notifications
- —Snapshot only: You see the state at one moment, not trends
- —Not scalable: Running CLI commands in a loop is fragile and resource-intensive
CLI is useful for quick troubleshooting but insufficient for production monitoring.
Method 2: Asterisk Manager Interface (AMI)
AMI is Asterisk's event-driven interface — the foundation most monitoring tools build upon. It provides real-time events for everything happening in your queues.
Setting Up AMI
Edit /etc/asterisk/manager.conf:
[general]
enabled = yes
port = 5038
bindaddr = 127.0.0.1
[monitor]
secret = your_secure_password
deny = 0.0.0.0/0.0.0.0
permit = 127.0.0.1/255.255.255.0
read = agent,call,reporting
write = agent,call,originateReload after changes:
asterisk -rx "manager reload"Key Queue Events
AMI emits events for every queue state change. The critical ones:
| Event | When It Fires | Key Fields |
|---|---|---|
QueueCallerJoin | Caller enters queue | Queue, Position, Count, CallerIDNum |
QueueCallerLeave | Caller exits queue | Queue, Position, Count, HoldTime |
QueueCallerAbandon | Caller hangs up waiting | Queue, Position, OriginalPosition, HoldTime |
QueueMemberStatus | Agent state changes | Queue, Interface, Status, Paused |
QueueMemberAdded | Agent logs into queue | Queue, MemberName, Interface |
QueueMemberRemoved | Agent logs out of queue | Queue, MemberName, Interface |
QueueMemberPause | Agent pauses/unpauses | Queue, Interface, Paused, Reason |
AgentConnect | Call connected to agent | Queue, Interface, HoldTime, RingTime |
AgentComplete | Agent finishes call | Queue, Interface, HoldTime, TalkTime |
Listening to AMI Events (Python Example)
Here's a minimal Python script to monitor queue events in real-time:
import socket
import re
def connect_ami(host='127.0.0.1', port=5038, user='monitor', secret='your_secure_password'):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((host, port))
# Read banner
sock.recv(1024)
# Login
sock.send(f'Action: Login\r\nUsername: {user}\r\nSecret: {secret}\r\n\r\n'.encode())
sock.recv(4096)
# Subscribe to queue events
sock.send('Action: QueueStatus\r\n\r\n'.encode())
print("Connected to AMI. Listening for queue events...")
buffer = ''
while True:
data = sock.recv(4096).decode('utf-8', errors='ignore')
buffer += data
while '\r\n\r\n' in buffer:
event, buffer = buffer.split('\r\n\r\n', 1)
if 'Event: Queue' in event or 'Event: Agent' in event:
print(f"\n{'='*50}")
print(event)
connect_ami()AMI Actions for Queue Control
Beyond listening to events, you can actively manage queues via AMI:
Action: QueueStatus # Get current state of all queues
Action: QueueSummary # Get summary statistics
Action: QueueAdd # Add agent to queue dynamically
Action: QueueRemove # Remove agent from queue
Action: QueuePause # Pause/unpause an agent
Action: QueueReset # Reset queue statistics
Limitations of Raw AMI
- —You build everything yourself: Parsing, storing, visualizing, alerting — all custom code
- —No historical data: Events stream in real-time but aren't stored unless you build that
- —Complex state management: Tracking agent states across multiple queues requires careful coding
- —No dashboards: You need a separate frontend for visualization
- —Maintenance burden: Custom AMI monitoring scripts become technical debt
AMI is powerful but requires significant development effort to turn into a usable monitoring solution.
Method 3: Queue Log File
Asterisk logs all queue events to /var/log/asterisk/queue_log. This is the basis for most historical reporting tools.
Queue Log Format
Each line follows this format:
UNIX_TIMESTAMP|CALLID|QUEUE|AGENT|EVENT|PARAM1|PARAM2|PARAM3
Example entries:
1710720000|1710719980.123|support|SIP/1001|CONNECT|18|1710719982.124|5
1710720180|1710719980.123|support|SIP/1001|COMPLETECALLER|18|180||
1710720200|1710720190.125|support|NONE|ABANDON|1|1|15
Key Events in Queue Log
| Event | Description | Parameters |
|---|---|---|
ENTERQUEUE | Caller entered queue | URL, CallerID |
CONNECT | Call connected to agent | HoldTime, BridgedChannel, RingTime |
COMPLETECALLER | Caller hung up after talking | HoldTime, TalkTime, Position |
COMPLETEAGENT | Agent hung up after talking | HoldTime, TalkTime, Position |
ABANDON | Caller abandoned before answer | Position, OrigPosition, WaitTime |
RINGNOANSWER | Agent didn't answer in time | RingTime |
TRANSFER | Call was transferred | Extension, Context |
PAUSE | Agent paused | Reason |
UNPAUSE | Agent unpaused | — |
Parsing Queue Logs (Bash)
Quick one-liner to check abandonment rate for today:
# Count today's events
TODAY=$(date +%s -d "today 00:00")
awk -F'|' -v start="$TODAY" '$1 >= start' /var/log/asterisk/queue_log | \
awk -F'|' '{events[$5]++} END {for(e in events) print e, events[e]}' | sort -k2 -rnLimitations
- —File-based: Parsing text files doesn't scale beyond a few thousand calls/day
- —No real-time dashboard: You parse after the fact
- —Rotation issues: Log rotation can lose data if not configured carefully
- —Manual aggregation: Computing KPIs like service level requires non-trivial scripting
Method 4: CDR and CEL Database Backend
For persistent storage, configure Asterisk to write CDR (Call Detail Records) or CEL (Channel Event Logging) to a database.
CDR to MySQL/PostgreSQL
In /etc/asterisk/cdr_adaptive_odbc.conf:
[asterisk_cdr]
connection = asterisk
table = cdr
alias start => calldate
alias clid => srcThis gives you SQL-queryable call records. However, CDR lacks queue-specific detail — you get call records but not queue metrics like hold time per queue, agent performance within queues, or abandonment reasons.
CEL for Detailed Events
CEL (Channel Event Logging) provides much more granular data than CDR. Configure in /etc/asterisk/cel_odbc.conf for database storage. CEL records events like CHAN_START, ANSWER, BRIDGE_ENTER, BRIDGE_EXIT, and HANGUP for every channel.
However, turning raw CEL events into meaningful queue dashboards requires:
- —Complex SQL queries joining multiple events
- —State machine logic to reconstruct call flows
- —Custom aggregation for KPIs
- —A visualization layer (Grafana, custom app, etc.)
This is where most DIY approaches either get stuck or accumulate months of engineering time.
Method 5: Open-Source Tools
Several open-source projects attempt to solve Asterisk queue monitoring:
QPanel
QPanel is a real-time panel for Asterisk and FreeSWITCH queues. It connects via AMI and shows live queue status.
Pros: Free, open-source, real-time display Cons: Minimal UI, no historical analytics, limited active development, no alerting, no KPI tracking
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.
MoniAst
A web-based Asterisk monitor panel showing real-time calls and extensions.
Pros: Real-time display, extension monitoring Cons: Basic queue support, no analytics, outdated codebase
CDR-Stats
Originally promising, CDR-Stats is a Django-based CDR analytics tool.
Pros: Was comprehensive Cons: Effectively abandoned — last meaningful update was years ago. Python 2 era code. Not recommended for new installations.
Grafana + Custom Dashboards
The DIY power option: store queue_log or CEL data in InfluxDB/TimescaleDB, build Grafana dashboards.
Pros: Flexible, free, powerful visualization Cons: Requires 40-80 hours of engineering to set up properly. Custom data pipelines. Ongoing maintenance. No out-of-the-box queue intelligence. You're building a product, not using one.
Method 6: Commercial Solutions
QueueMetrics
The legacy incumbent. Java-based, has been around since 2005.
Pricing: From CHF 8/agent/month (cloud) or one-time license fee Pros: Comprehensive reporting, mature product, wallboard support Cons: Java dependency (requires Tomcat), dated UI, complex installation, expensive at scale (50 agents = CHF 400/month), slow to innovate
Asternic Call Center Stats
Focused on queue reporting.
Pricing: Commercial license required for full features Pros: Direct queue_log integration, report generation Cons: Primarily historical reporting (not real-time), outdated interface, limited dashboard customization, PHP-based legacy code
Astervis
Modern SaaS purpose-built for Asterisk queue monitoring and analytics.
Pricing: From $49/month (10 agents) to custom Enterprise plans Installation: One command — connects via AMI, no Java, no PHP, no complex dependencies
Key differentiators:
- —30+ real-time charts: Heatmaps, queue performance, operator dashboards, trunk analytics — all updating live
- —Operator performance tracking: Individual KPIs, leaderboards, handle time trends, first-call resolution by agent
- —One-command install:
curl -fsSL https://get.astervis.io | bash— running in under 5 minutes - —Self-hosted: Your data stays on your infrastructure. GDPR-friendly by design.
- —CRM integration: Native Bitrix24 and AmoCRM connectors — see caller history during calls
- —Call recording playback: Listen to recordings directly in the analytics dashboard
- —Modern stack: Built on TimescaleDB for time-series analytics, not legacy databases
- —14-day free trial: No credit card required
Choosing the Right Approach
Here's a decision matrix:
| Approach | Setup Time | Real-Time | Historical | Alerting | Cost | Best For |
|---|---|---|---|---|---|---|
| CLI Commands | 0 min | Snapshot | No | No | Free | Quick troubleshooting |
| AMI Script | 20+ hrs | Yes | DIY | DIY | Free | Developers building custom tools |
| Queue Log Parsing | 5+ hrs | No | Basic | No | Free | Simple historical checks |
| CDR/CEL + Grafana | 40-80 hrs | Partial | Yes | DIY | Free | Teams with engineering resources |
| QPanel | 1-2 hrs | Yes | No | No | Free | Basic real-time display only |
| QueueMetrics | 2-4 hrs | Yes | Yes | Yes | $$$ | Legacy environments, large budgets |
| Astervis | 5 min | Yes | Yes | Yes | $49/mo+ | Production call centers |
Setting Up Real-Time Monitoring with Astervis
If you want to go from zero to full real-time queue monitoring in under 10 minutes, here's the path:
Step 1: Install Astervis
On your Asterisk server (or a separate monitoring server with AMI access):
curl -fsSL https://get.astervis.io | bashThe installer auto-detects your Asterisk configuration, sets up the database, and starts the monitoring service.
Step 2: Configure AMI Connection
Ensure AMI is enabled in your /etc/asterisk/manager.conf (see Method 2 above). Astervis needs read access to agent, call, and reporting events.
Step 3: Access Your Dashboard
Open http://your-server:3000 in your browser. You'll immediately see:
- —Live queue status: Calls waiting, agents available, current wait times
- —Heatmap: Call volume patterns by hour and day of week
- —Agent dashboard: Who's on a call, who's available, who's paused
- —SLA tracking: Real-time service level against your targets
- —Trunk utilization: Active channels per trunk
Step 4: Set Up Alerts (Optional)
Configure notifications for:
- —Queue wait time exceeding threshold (e.g., 60 seconds)
- —Abandonment rate spike
- —All agents unavailable
- —Trunk capacity above 80%
Key Metrics to Track
Once your real-time monitoring is running, focus on these queue KPIs:
Service Level (SL)
Formula: (Calls answered within target time / Total calls) × 100
Industry standard target: 80/20 (80% of calls answered within 20 seconds). Track this in real-time to catch SLA breaches before they accumulate.
Average Speed of Answer (ASA)
Formula: Total wait time for answered calls / Number of answered calls
Target: Under 30 seconds for most call centers. If ASA trends upward during the day, you need more agents in queue.
Abandonment Rate
Formula: (Abandoned calls / Total calls entering queue) × 100
Target: Under 5%. An abandonment rate above 8% usually indicates understaffing or routing problems.
Agent Occupancy
Formula: (Total handle time / Total logged-in time) × 100
Target: 75-85%. Below 70% means overstaffing. Above 90% leads to burnout and quality drops.
First Call Resolution (FCR)
Track how many callers are resolved without callbacks or transfers. This requires call outcome tracking — a feature available in advanced platforms like Astervis that combine CDR data with queue metrics.
Best Practices for Asterisk Queue Monitoring
- —
Monitor 24/7, not just business hours: After-hours calls often reveal trunk issues, misconfigured failovers, or unexpected call patterns.
- —
Set baseline metrics first: Run monitoring for 2 weeks before setting alert thresholds. Every call center has different "normal."
- —
Use heatmaps for staffing: Real-time monitoring is about the present, but heatmaps reveal patterns for future staffing decisions.
- —
Track trends, not just snapshots: A queue with 3 callers waiting is fine if it's trending down, alarming if trending up. Good monitoring shows both.
- —
Combine queue metrics with call quality: Queue times mean nothing if calls have audio issues. Monitor both simultaneously.
- —
Review weekly, optimize monthly: Use historical data for weekly team reviews and monthly process optimization.
Conclusion
Real-time Asterisk queue monitoring isn't optional for serious call centers — it's the difference between proactive management and constant firefighting.
If you're starting from scratch, skip the DIY approaches unless you have dedicated engineering resources. Modern tools like Astervis give you 30+ real-time charts, operator performance tracking, and CRM integration — all self-hosted on your infrastructure — in under 10 minutes.
Start your free 14-day trial — no credit card required. See what's really happening in your Asterisk queues today.
Running FreePBX? Check out our guide: FreePBX Call Center Reporting: How to Get Real-Time Analytics
Comparing tools? Read: Best Asterisk Monitoring Tools in 2026
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.
