How to set up uptime monitoring for your VICIdial server

An ICMP ping check that shows green while your dialer is broken is worse than no monitor at all — it creates false confidence and delays the moment you realize something is wrong. VICIdial is healthy only when Asterisk is up, SIP (Session Initiation Protocol) registrations are working, and the web admin responds over HTTPS. A ping proves none of those things. This post walks through what to monitor on a production VICIdial server, which endpoints reveal real dialer health, and how to configure an external uptime monitor that actually tells you when the dialer is down.

Why a ping check is not enough

The Linux kernel can answer ICMP echo requests while Asterisk is crashed, while the web admin is throwing HTTP 500 errors, and while Agent sessions cannot connect. A dialer that pings fine but cannot place calls or accept SIP (Session Initiation Protocol) registrations is offline from the business perspective even though the monitor shows green. The check needs to probe something that only passes when the dialer is actually capable of taking and placing calls.

The three things to monitor on a VICIdial server

Prioritize these three targets in order of business impact:

• HTTPS response on the web admin — send an HTTP GET to the server's branded subdomain over port 443 and expect a 200 or 302 status. If this fails, agents cannot log in, supervisors cannot access reports, and Agent session management is impossible. This is the highest-priority check.
• Asterisk being up — the most reliable probe is a TCP connect check on port 5038, where the AMI (Asterisk Manager Interface) interface listens. If Asterisk is down, no Channel can be opened and no calls can be placed or received. A TCP connect to 5038 that gets a connection banner confirms Asterisk is running.
• SIP registration health — if your agents use Softphone clients or a Webphone, the SIP registrar must be accepting registrations on port 5060 or 5160. A SIP OPTIONS probe to that port should return a 200 OK when the service is healthy. If your monitor does not support SIP OPTIONS natively, a TCP connect to 5060 is a reasonable fallback.

flowchart LR
  M["External monitor"] --> P["HTTPS :443"]
  M --> A["Asterisk AMI :5038"]
  M --> S["SIP OPTIONS :5060"]
  P --> R1{"2xx / 3xx?"}
  A --> R2{"TCP banner?"}
  S --> R3{"200 OK?"}
  R1 -->|No| AL["Alert: web admin down"]
  R2 -->|No| AL2["Alert: Asterisk down"]
  R3 -->|No| AL3["Alert: SIP registrar down"]

Setting up UptimeRobot or BetterStack

Both UptimeRobot and BetterStack offer a free tier that covers the basics for a single dialer. For the HTTPS check: create a new HTTP(S) monitor, point it at your VICIdial server's branded domain or IP, set the check interval to one or two minutes, and optionally specify a keyword in the response body to verify the correct page is loading rather than a generic error page from a proxy. For the Asterisk check: use a TCP port monitor pointed at port 5038 on the server's IP address.

Alert routing matters as much as the check itself. Email alerts alone are too slow for a call center environment. Wire the alert to a Telegram channel, a Slack webhook, or an on-call rotation tool so whoever is available sees the alert within seconds, not minutes. A dialer that is down for five minutes during a morning shift can cost more in dropped contacts than the price of a better alerting setup.

How VICIfast health checks relate to external monitors

VICIfast publishes a status page and runs uptime monitors against its own infrastructure. For each Single tenant customer server, the VICIfast health check system continuously polls the box and exposes the HEALTHY, DEGRADED, UNREACHABLE, or UNKNOWN status directly on the dashboard. You can complement that with your own external monitor pointed at your specific branded subdomain — both views together give you the most complete picture.

External monitors catch situations where the platform's internal checks and your server are both having a connectivity issue from the same network. A probe from a third-party network like UptimeRobot's global check nodes confirms whether the server is reachable from the public internet, independent of VICIfast's internal view. Using both in parallel removes blind spots.

For the full picture of what the platform checks and how health states work together, see our server health and capacity guide. To understand what the SIP peers check specifically tests and why it matters, see checking the SIP peers registry in VICIdial.

If you want built-in server health monitoring without wiring up your own stack from scratch, see VICIfast plans — your server is provisioned and monitored in under 40 seconds.