Find why a VICIdial agent is not dialing

1. Decide whether automatic dialing should happen

1. In the affected Agent session, note the campaign ID and time, including time zone. In Campaigns → Show Campaigns, open that same ID’s Modify screen. Read the saved Dial Method, Auto Dial Level and Active values before touching a control.
2. Compare those values with the type of work expected: agent-initiated manual call, automatic outbound work or inbound call delivery. Use the matching row below; do not troubleshoot the outbound hopper for an inbound-only symptom.
3. If the intended mode is unknown, leave the campaign unchanged and record that missing decision in the handoff. If a live incident requires a change, use the campaign owner’s approved values rather than copying this lab’s controls.

Saved lab campaign: inactive

Open to enlarge

Saved lab campaign: manual mode

Open to enlarge

Saved lab campaign: zero automatic dial level

Open to enlarge

You should seeYou have selected the correct branch. MANUAL with no automatic attempts is expected behavior; Active N is a deliberate stop until an activation is approved.

Follow the approved manual call workflow →

Trace inbound DID routing →

2. Verify the affected agent is available on the same campaign

1. On the Agent screen, compare the logged-in user and campaign with the incident record. Read the current state: PAUSED, waiting/available, in a call, or waiting for disposition. Use Admin’s real-time report for the same user as a second observation if you have access.
2. If PAUSED is intentional, record it as the stop state. Only when the agent is actually ready for the approved work, select RESUME and check that the screen changes to its available/waiting state. Complete any pending disposition through the normal Agent workflow before expecting another call.
3. If the station connection or session audio is absent, stop this branch and follow the phone-login or station setup guide. Reaching an Agent page is not proof of a connected phone leg.
4. If the Agent screen and live report disagree after their normal refresh, record both states and the same timestamp. Preserve the session for the supervisor to inspect; do not delete live-agent rows or reset campaigns.

Idle Agent screen with call controls and blank lead details.

Open to enlarge

You should seeMatch: the same user/campaign is available with the expected station session. Different: a pause, pending work or station failure explains the next action. Unknown: send the paired observations to the session owner.

Resolve a rejected station login →

Check the phone or WebRTC station →

3. Match one intended lead to the campaign’s eligibility gates

1. In Lists → Show Lists, open the list containing the authorized test lead or affected work. Compare its saved Campaign and Active controls with the campaign from step 1. Record the values before any correction.
2. In the campaign Modify screen, read Dial Statuses, Local Call Time and any lead filter or recycle rule in use. Through the authorized lead-search screen, inspect one intended lead’s status and list ID without copying its phone number or personal fields into a ticket.
3. Compare the lead’s status with an allowed Dial Status, its list with the selected campaign, and the current time with the applicable lead-local calling window. A NEW lead is eligible by status only when NEW is among the campaign’s dial statuses; a list’s total count is not its eligible count.
4. If a list association or Active flag is wrong on an approved isolated test, record the old value, change only that field, SUBMIT and reopen the record. If the block is a calling window, consent rule, filter or retry limit, honor that rule or have its owner correct the underlying test data; do not disable it to force a call.
5. If everything visible matches but eligibility is still unknown, record the specific filter/recycle rule for the campaign owner. Do not reset called statuses or the entire hopper as a first diagnostic.

List

Your actual list ID → same campaign IDReopen after an approved save; an unsaved dropdown is not evidence.

Lead status

A status present in the campaign’s Dial StatusesUse an authorized record; report only the status and a safe internal reference.

Time / filters

Within the applicable window and included by the configured rulesCheck the relevant time zone; server time and lead-local time can differ.

Where to compare the list’s campaign and active flag

Open to enlarge

You should seeYou can name either a failed eligibility rule or one specific intended lead whose visible gates match. That is enough to proceed to staging; it is not proof a call was attempted.

4. Check whether eligible work is staged for this campaign

1. If you have only Admin access, use the campaign’s hopper view/count available in your build and record its timestamp. If that view is unavailable, give the read-only database owner the aggregate query below; do not create a broader login during an incident.
2. For a local SQL check, first complete Create a read-only database account for safe VICIdial queries. Open the client with sudo mysql --defaults-file=/etc/vicidial-readonly.cnf and verify SELECT CURRENT_USER(), DATABASE(); before entering this query.
3. Replace REPLACE_WITH_CAMPAIGN_ID with the exact campaign ID from step 1. Keep the surrounding single quotes. For an ID containing a quote, have the database owner supply a correctly quoted value instead of editing SQL by trial and error.
4. Run the query, record the status counts and time, then type quit to leave the client. After an approved eligibility correction, allow the site’s normal hopper refresh and check once more; do not interpret a single instant as a permanent state.

SELECT status, COUNT(*) AS queued_leadsFROM vicidial_hopperWHERE campaign_id = 'REPLACE_WITH_CAMPAIGN_ID'GROUP BY status;

You should seeThe aggregate distinguishes no staged rows from staged work at that moment. It does not identify a dialplan failure or prove a dial attempt.

Set up and verify the read-only client →

Trace a call attempt through the dialplan →

5. Verify one correction or hand off the first unresolved gate

1. For an approved change, reopen the exact record and confirm the saved value. Keep its original value in your change record and wait for the normal report/hopper refresh before comparing again.
2. If testing is authorized, use one approved test destination in the intended workflow. Observe the Agent state and supervisor report together: did an attempt start, did it reach the intended destination, and did the final disposition save? Record these as separate results.
3. If the same symptom remains, return the changed field to its recorded value when that rollback is appropriate for the approved change, SUBMIT and reopen. Do not compound the uncertainty with unrelated dial-level, status-reset or carrier changes.
4. Complete the handoff below with observed values and the earliest unknown or failing gate. Omit passwords, phone numbers, lead names and raw database rows. A diagnosis with a precise owner/check is a completed diagnostic outcome even when no call was authorized.

Observed at / time zone:Campaign ID / intended work:Saved Dial Method / Active / Auto Dial Level:Agent user / campaign / state / station observation:List ID / saved campaign / Active:Lead status / allowed status / calling-window result:Hopper status counts / observed at (or UNKNOWN):First failed or unknown gate:One approved change / original value / saved value:Retest: no test | no attempt | attempt failed | destination reachedDisposition saved / rollback confirmed:Next owner / exact next check:

You should seeDone means either the original symptom was reproduced and the approved correction was verified, or the next owner has the exact failing/unknown gate and evidence needed to continue. A screenshot or a positive hopper count is not a completed call.

Recorded lab terminal checks

Recorded lab checks were run against the synthetic demo on November 4, 2026. These read-only observations supplement the configuration steps above; they do not establish that a call, route, recording or report workflow succeeded.

Recorded lab observation: At capture LAB01 was inactive and MANUAL; this is a configuration observation, not proof of dial readiness.

Recorded lab observation: List 90001 was active and associated with LAB01; active list does not override inactive campaign.

Recorded lab observation: Three synthetic lab leads were NEW. Status counts do not prove eligibility, successful dialing or lead handling.

Recorded lab observation: No matching hopper rows at capture; this alone does not diagnose a fault or justify a reset.

mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --batch vicidb -e "SELECT campaign_id, active, dial_method FROM vicidial_campaigns WHERE campaign_id='LAB01';"mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --batch vicidb -e "SELECT list_id, campaign_id, active FROM vicidial_lists WHERE list_id=90001 AND campaign_id='LAB01';"mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --batch vicidb -e "SELECT status, COUNT(*) AS lead_count FROM vicidial_list WHERE list_id=90001 GROUP BY status ORDER BY status;"mysql --defaults-extra-file=/etc/vicidial-readonly.cnf --batch vicidb -e "SELECT COUNT(*) AS hopper_count FROM vicidial_hopper WHERE campaign_id='LAB01' AND list_id=90001;"

View still screenshots

Recorded lab terminal: lab campaign

Open to enlarge

Recorded lab terminal: lab list

Open to enlarge

You should seeThe recorded lab command and output show exactly what the demo returned. Use the original workflow’s separate end-to-end acceptance checks before declaring success.