VICIdial & agents · Beginner practical guide

VICIdial call count limits: stop calling the same lead too often

Choose between lifetime, daily and rolling 24-hour limits, inspect the real switches, and work through a small attempt ledger before testing a campaign.

Start the guide

By Vicigeek Editorial DeskStep-by-step guide7 minute readUpdated November 7, 2026

01 / 09

Start here: decide what you want to limit

A lead is one contact record. A phone number can appear in several lead records. Decide whether your rule follows the record or the number, then decide whether it means a calendar day or the previous 24 hours. Those choices can produce different answers for the same call history.

Check the system switch, campaign and call method before changing a saved limit. Do not raise it just because a lead stopped dialing.

You should seeThe configured manual daily boundary rejected the next request without placing another customer call.

02 / 09

1. Choose the right counter

Use the table to name the rule before opening the settings. A value of zero disables the documented lifetime and lead-daily limit; treat zero as no restriction, not as zero permitted calls. Check the exact help for the other fields in your installed build.

Four counters that answer different questionsScroll sideways to compare columns
Counter	What follows the count	When the window changes
Lifetime lead	One lead record	Uses that lead’s accumulated called count; midnight does not clear it.
Daily lead	One lead record	A new day starts at midnight in server time.
Daily phone number	The same number across participating campaigns	Resets at the System Settings Timeclock End of Day time.
Rolling 24-hour	A lead or number; choose the scope	Uses database time and a moving look-back window, not midnight.

03 / 09

2. Inspect one campaign without changing it

Pick one named campaign and keep a private before record of its values and the observation time. Otherwise you may explain the wrong campaign’s behavior.

Open Admin → System Settings. Find Enable Daily Called Count Limits and Enable 24-Hour Called Count Limits. Record whether each is enabled; leave the page without submitting.
Find Timeclock End of Day and record the server time zone. Your laptop clock is not the counter’s reset clock.
Open Campaigns → your lab campaign → Detail. Find Call Count Limit and Daily Call Count Limit.
Find Daily Call Limit Manual. Counting manual attempts and restricting manual attempts are separate behaviors; read the selected option’s help.
Find Daily Phone Number Call Limit and the four 24-Hour Called Count settings: Method, Scope, Limit and Override.
For a rolling rule, write down LEAD or PHONE_NUMBER, then SYSTEM_WIDE or CAMPAIGN_LISTS. An override container can change the effective maximum.

You should seeYou have one complete rule: system switch, campaign, identity, scope, clock, maximum and manual-call behavior.

04 / 09

3. Check the database clock and schema safely

Use an approved read-only SQL session to inspect the clock and table names. Missing tables or access errors need an administrator’s review; the historical migration appendix is not a repair command.

Before you use it: Use the approved read-only session for the VICIdial database. The sample was not executed as written.

SELECT NOW() AS database_now,       @@session.time_zone AS session_time_zone,       @@system_time_zone AS system_time_zone;SHOW TABLES LIKE 'vicidial_lead%count%';SHOW TABLES LIKE 'vicidial_lead_24hour_calls';SHOW TABLES LIKE 'vicidial_phone_number_call_daily_counts';

Not executed · deliberately not run on the demo

This sample changes a system, contacts an outside service, needs a live call, or would print real data from a shared server, so it was not run on the demo. Run it only where you are authorized, and compare the result with the success and stop guidance.

Success looks like: The clock and table names can be compared with your campaign record. Table existence establishes availability, not enforcement.
Stop if: For a missing table or privilege error, stop and confirm the installed revision and account permissions; do not create a replacement table.

05 / 09

4. Work through a five-attempt example

Our offline worksheet uses fictional labels and a fixed clock: November 7 at 12:00 UTC. LEAD_A and LEAD_B share PHONE_A; LEAD_C uses PHONE_B. One older attempt falls outside the 24-hour window. The table deliberately avoids the exact expiry second, where an installation’s boundary comparison needs separate inspection.

The local arithmetic check passed all six comparisons below. It made no VICIdial connection and proves no dialing gate; it defines expectations before a real test.

Before you use it: These fictional labels are not live lead IDs or dialable numbers. Count the rows that match each question below.

Example clock: 2026-11-07 12:00 UTCTime (UTC)       Lead    List        Phone    TypeNov 06 10:30      A       LAB         A        AUTONov 06 22:30      A       LAB         A        AUTONov 07 07:30      B       OTHER       A        MANUALNov 07 11:00      A       LAB         A        AUTONov 07 10:30      C       LAB         B        AUTO

Not executed · worksheet or reference text

This sample is a template or reading aid, not a terminal command. There is no output to show.

Success looks like: Each result follows the chosen identity, list scope and time window.
Stop if: If your answer differs, check all three filters before changing any real campaign setting.

Same history, different question: checked synthetic arithmeticScroll sideways to compare columns
Question at 12:00 UTC	Count	Why it differs
LEAD_A since midnight	1	Only its 11:00 attempt is today.
LEAD_A in the last 24 hours	2	Its previous-day 22:30 attempt still counts.
PHONE_A, last 24 hours, all lists	3	Includes LEAD_B’s 07:30 attempt to the same number.
PHONE_A, last 24 hours, lab list only	2	The other list is excluded from this example.
PHONE_A since midnight	2	Both today’s matching-number attempts are included.
PHONE_A since an example 09:00 reset	1	The 07:30 attempt precedes this reset.

You should seeAt a hypothetical maximum of three, the all-lists phone count is already at the limit while LEAD_A’s rolling count is still below it. The setting choice changes the expected next step.

06 / 09

5. Practical checks and their limits

We enabled the daily feature only for the approved lab test. Before doing so, a read-only check found no other campaign with a configured related nonzero limit. The synthetic campaign used a hypothetical daily limit of 2 and Daily Call Limit Manual COUNT_AND_RESTRICT. This number is a test value, not a legal recommendation.

The same synthetic lead already had one real manual attempt. The proper internal call raised its actual daily total and manual counts to 2. The next manual preview request returned the literal backend response DAILY CALL LIMIT, with no DIAL LEAD action or new customer Originate.

The rejection left the dial-log rows and daily total/manual counts at 2. This verifies that selected manual daily-limit boundary on the installed build. We did not reset the lead or erase its earlier attempt to make the result easier to obtain.

The lifetime, rolling 24-hour and phone-number scopes are explained and rehearsed in the worksheet. They were not all exercised as live enforcement cases. A failed or unrecorded call attempt can still count; a stereo file is not the call-attempt counter.

Actual allowed-versus-rejected manual daily testScroll sideways to compare columns
Step	Daily total/manual count	Result
Before the proper call	1 / 1	One earlier attempt retained.
Proper internal call	2 / 2	Allowed at a limit of 2.
Next preview request	Still 2 / 2	DAILY CALL LIMIT; no third customer dial.

Native LAB01 call-count settings before the test showing the actual recorded value — Actual read-only LAB01 Detail fields: Call Count Limit 0, Call Count Target 3 and Manual Restrict DISABLED.
Capture details
Target 3 is a different field and does not turn the lifetime limit of 0 into a cap. Daily and 24-hour controls were hidden by the disabled system gates.

You should seeThe configured manual daily boundary rejected the next request without placing another customer call.

Download the dated practical test results and limits

07 / 09

6. Prepare a controlled enforcement test

A complete test needs both a permitted attempt and a rejected next attempt. Configuration inspection alone cannot establish either. Keep this plan in the inactive lab until an administrator approves the fixture, route and call scope.

Use one synthetic lead and an internal destination whose entire route you have checked. Exclude carrier access from the test route.
Record the existing counters, time, campaign and any matching override. Choose one limit to test; leave unrelated limits unchanged.
Write the expected count before each attempt. Include a second synthetic lead with the same internal number only if testing PHONE_NUMBER versus LEAD.
Run only the approved attempts. Check the actual call result and the appropriate counter, not just a ringing indicator.
For a rejected attempt, record the application’s reason and confirm no call reached the destination. Check manual behavior separately when that is part of the requirement.
Restore the campaign values and deactivate the fixture. Keep the test history as evidence; do not wipe counters to manufacture a pass.

You should seeCall this enforcement verified only after the observed permitted and blocked attempts agree with the recorded rule.

08 / 09

7. When the result looks wrong

Keep the attempt time and exact lead ID when investigating. Two rows with the same number are still different leads, and two limits with the word daily may use different reset times.

Diagnose the mismatch before loosening a limitScroll sideways to compare columns
Symptom	Check next
It still calls after the expected count	System enable switch, selected campaign, manual option, override and documented callback exception.
It stopped after fewer calls than this lead shows	PHONE_NUMBER mode may include other lead records; SYSTEM_WIDE may include other lists.
Midnight passed but the call is still blocked	A rolling 24-hour window does not reset at midnight. Compare the database clock.
Raising today’s lead limit did not resume dialing	The called-since-last-reset flag may remain set. Review an approved list-reset plan; do not reset a whole live list as a quick fix.
A few extra attempts appear	Inspect recycling, alternate-number dialing and the exact call method rather than assuming a universal hard cap.

09 / 09

8. Restore the plan and keep a useful record

Stop the fixture after an unexpected result. Keep settings, timestamps, synthetic identifiers and the observed reason so another administrator can investigate without guessing.

Restore only values changed for the approved test and confirm the saved page shows them.
Leave the campaign inactive and remove the synthetic test destination from any future dialing scope.
Do not update count tables or called-since-last-reset by hand. Ask the administrator to review any necessary recovery using the supported application controls.

Correct lead or phone identity
Correct campaign and list scope
Correct server/database clock
Both allowed and blocked outcomes recorded, or the enforcement gap explicitly retained

Checks and sources

What was checked

November 7, 2026: the actual permitted call, daily total/manual count of 2, literal backend rejection and absence of a new customer Originate were observed.
Only the selected manual daily-limit boundary was live-tested. The other counter methods and scopes are source-reviewed worked examples.

Primary references

Sources

VICIdial Call Count LimitsVICIdial Group · accessed November 7, 2026
MariaDB NOW referenceMariaDB · accessed November 7, 2026
MariaDB SELECT referenceMariaDB · accessed November 7, 2026