How to watch disk usage on a busy dialer

On a busy VICIdial server, three things grow without limit until you stop them: Call recording files, Asterisk log files, and the VICIdial MySQL database. They all live on the same disk the dialer depends on. When that disk fills, calls stop, agents get dropped, and the system can corrupt data mid-write. Watching disk usage is not a set-it-and-forget-it task on a production dialer — it needs a recurring check and a plan for what to do when the number climbs.

What grows on the disk

Call recordings are by far the biggest consumer. A G.711 recording runs around 1 MB per minute of Talk time. At 20 agents each averaging five hours of talk time a day, that is about 6 GB of new audio every 24 hours. After a month of dialing you are looking at 180 GB from recordings alone. High-volume centers running two or three shifts can fill a 500 GB disk within weeks if nothing is removed.

Log files are the second culprit. Asterisk writes a full log per day by default. VICIdial writes its own Keepalive and process logs. These are individually smaller than recordings but they accumulate steadily. Default installations rarely rotate and compress logs aggressively enough, and after six months you can find several gigabytes of log data that is no longer useful to anyone.

The database is the third item. The vicidial_log and vicidial_closer_log tables grow with every Disposition written. Larger call centers accumulate tens of millions of rows over a year. The tables themselves may stay manageable in row count, but the on-disk size of the MySQL data directory can grow quietly into tens of gigabytes without anyone noticing until something breaks.

Checking disk percent-used with df

The quickest way to check disk percent-used is to SSH into the box and run df -h. The output shows every mounted filesystem, its total size, how much is used, how much is free, and the percent-used in one column. You care about the row that mounts at / — that is the root filesystem where recordings, logs, and the database all land on a standard VICIdial install. If you have a separate volume for recordings or MySQL data, check that row too.

A practical threshold: treat 75% used as a warning that needs attention this week, and 90% as a hard alarm that needs same-day action. Do not wait for 99% — at that point the OS itself cannot write temp files and the dialer will start failing in unpredictable ways. MySQL may refuse to write new rows. Asterisk may fail to record calls. The VICIdial keepalive logs may stop updating. All of these failures can be silent or misleading if you do not already know the disk is full.

flowchart TD
  A["Run df -h on the box"] --> B{"/ percent-used?"}
  B -->|"< 75%"| C["Healthy — schedule next check"]
  B -->|"> 75%"| D{"What is largest?"}
  D --> E["Check recording dir with du -sh"]
  D --> F["Check log dir size"]
  D --> G["Check MySQL data dir size"]
  E --> H["Archive or delete old recordings"]
  F --> I["Rotate and compress logs"]
  G --> J["Purge old call-log rows"]

Setting recording retention

VICIdial does not delete old recordings automatically. You need to decide how long you are legally required to keep them and then set up a cron job that removes anything older than that window. A simple find /path/to/recordings -mtime +90 -delete keeps the last 90 days and drops everything older. Run it nightly during low-traffic hours so it does not compete with active recording writes.

Before you delete anything, check your compliance obligations. Many regulated industries require recordings to be kept for 12 to 36 months. If storage cost is the concern, archive older recordings to object storage first, confirm the upload, and then remove the local copies. This is cheaper than expanding the disk and keeps you inside your retention policy.

Where disk space appears in the admin UI

The Server Versions page in the VICIdial admin area shows disk space alongside the server load and channel count. It gives you a quick at-a-glance figure when you are already in the admin screen and do not want to open an SSH session. The number updates on page load rather than in real time, so treat it as a spot check rather than a live graph. For a continuous view, use an external monitor that polls disk at a scheduled interval and alerts you before the threshold is crossed, not after.

For a broader look at how disk fits into the overall server health picture, read our server health and capacity guide. For specifically what the Server Versions page shows and how to read it, see our post on monitoring disk space via the Server Versions page.

On VICIfast, recordings stay on the customer's own dedicated server — you are not sharing storage with other tenants. Each server is Single tenant and sized for the workload. If you want a properly sized box with disk monitoring built in from day one, see VICIfast plans — your server is live in under 40 seconds.