·13 min·1 views

How to Monitor Asterisk Queues in Real-Time: Complete Guide

Every method to monitor Asterisk queues in real-time — from CLI commands and AMI events to analytics platforms. Code examples, comparison table, and setup instructions.

A
Astervis
Engineering & product team

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,originate

Reload after changes:

asterisk -rx "manager reload"

Key Queue Events

AMI emits events for every queue state change. The critical ones:

EventWhen It FiresKey Fields
QueueCallerJoinCaller enters queueQueue, Position, Count, CallerIDNum
QueueCallerLeaveCaller exits queueQueue, Position, Count, HoldTime
QueueCallerAbandonCaller hangs up waitingQueue, Position, OriginalPosition, HoldTime
QueueMemberStatusAgent state changesQueue, Interface, Status, Paused
QueueMemberAddedAgent logs into queueQueue, MemberName, Interface
QueueMemberRemovedAgent logs out of queueQueue, MemberName, Interface
QueueMemberPauseAgent pauses/unpausesQueue, Interface, Paused, Reason
AgentConnectCall connected to agentQueue, Interface, HoldTime, RingTime
AgentCompleteAgent finishes callQueue, 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

EventDescriptionParameters
ENTERQUEUECaller entered queueURL, CallerID
CONNECTCall connected to agentHoldTime, BridgedChannel, RingTime
COMPLETECALLERCaller hung up after talkingHoldTime, TalkTime, Position
COMPLETEAGENTAgent hung up after talkingHoldTime, TalkTime, Position
ABANDONCaller abandoned before answerPosition, OrigPosition, WaitTime
RINGNOANSWERAgent didn't answer in timeRingTime
TRANSFERCall was transferredExtension, Context
PAUSEAgent pausedReason
UNPAUSEAgent 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 -rn

Limitations

  • 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 => src

This 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:

  1. Complex SQL queries joining multiple events
  2. State machine logic to reconstruct call flows
  3. Custom aggregation for KPIs
  4. 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.

Try Free

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:

ApproachSetup TimeReal-TimeHistoricalAlertingCostBest For
CLI Commands0 minSnapshotNoNoFreeQuick troubleshooting
AMI Script20+ hrsYesDIYDIYFreeDevelopers building custom tools
Queue Log Parsing5+ hrsNoBasicNoFreeSimple historical checks
CDR/CEL + Grafana40-80 hrsPartialYesDIYFreeTeams with engineering resources
QPanel1-2 hrsYesNoNoFreeBasic real-time display only
QueueMetrics2-4 hrsYesYesYes$$$Legacy environments, large budgets
Astervis5 minYesYesYes$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 | bash

The 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

  1. Monitor 24/7, not just business hours: After-hours calls often reveal trunk issues, misconfigured failovers, or unexpected call patterns.

  2. Set baseline metrics first: Run monitoring for 2 weeks before setting alert thresholds. Every call center has different "normal."

  3. Use heatmaps for staffing: Real-time monitoring is about the present, but heatmaps reveal patterns for future staffing decisions.

  4. 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.

  5. Combine queue metrics with call quality: Queue times mean nothing if calls have audio issues. Monitor both simultaneously.

  6. 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.

Share this article