TIMEOT — Timeout

What TIMEOT Means

A system timeout occurred — the call was not answered, connected, or dispositioned within the configured timeout period. Different from NA in that TIMEOT may indicate a system-level timeout rather than a ring timeout.

When This Status Is Set

TIMEOT is assigned when VICIdial’s internal call-processing timeout mechanisms fire on a call that could not be completed, connected, or dispositioned within the configured time limits. Unlike NA, which represents a clean ring-timeout at the carrier level, TIMEOT typically indicates a system-level timeout — the call processing pipeline stalled due to server load, database latency, network congestion between VICIdial components, or Asterisk AGI script timeouts. TIMEOT can also fire when the vicidial_manager process fails to receive a call-status update within its expected window, causing the system to time out the call attempt and disposition it as TIMEOT rather than leaving it in an indeterminate state. The specific timeout thresholds are determined by various VICIdial configuration parameters and Asterisk channel timeout settings.

Impact on List Management

TIMEOT leads are typically recyclable and should be included in your dial_status_filter, since the timeout was usually caused by a system-side issue rather than the contact being unreachable. However, TIMEOT rates that exceed 2-3% of total dials should trigger an immediate infrastructure investigation — this level of timeout failures indicates that your server is under stress, your database is experiencing lock contention, or your network is introducing unacceptable latency between VICIdial components. Track TIMEOT volumes by hour and correlate them with server load metrics (CPU utilization, MySQL slow query log, network throughput) to identify whether the timeouts cluster during peak dialing periods when the system is under maximum load. A sudden spike in TIMEOT with no corresponding change in dial volume suggests a hardware failure, disk I/O bottleneck, or a runaway database query consuming server resources.

Best Practices

• Include TIMEOT in dial_status_filter for recycling — these leads were likely not actually reached, so they deserve another attempt

• High TIMEOT rates warrant server performance investigation — check CPU utilization, MySQL process list, disk I/O, and network latency between the web, telephony, and database servers

• Distinguish TIMEOT from NA in reporting to separate system issues from contact behavior — TIMEOT is a system health metric, not a list quality metric

• Correlate TIMEOT spikes with other system events (backups, log rotation, cron jobs, high simultaneous agent counts) to identify competing resource demands

• After resolving the infrastructure issue, recycle accumulated TIMEOT leads with high priority since they never received a genuine dial attempt

Admin Configuration

TIMEOT is a system-level status defined in Admin → System Statuses with callable set to Y and selectable set to N — it is auto-assigned by the system’s timeout handling processes. The timeout thresholds that trigger TIMEOT are influenced by several settings: the campaign’s dial_timeout in Campaign Detail → Dialing Options, the Asterisk channel timeout values, and VICIdial’s internal process monitoring intervals. Lead recycling for TIMEOT is configured in Campaign Detail → Lead Recycling with a short delay since the leads likely never reached the contact. To diagnose TIMEOT causes, review the VICIdial system logs, the Asterisk full log (/var/log/asterisk/full), and the MySQL slow query log for the time period when TIMEOT events occurred.

ViciStack’s List Management module monitors disposition distribution in real time — automatically adjusting recycling logic, dial_status_filter priorities, and hopper fill strategies based on how your dispositions are trending. No manual SQL, no spreadsheet audits.