Year 1 FREE | No per-agent fees, unlimited callsView Pricing Plans
Back to BlogFreeSWITCH

FreeSWITCH High Availability: Clustering and Failover Strategies

How to build a fault-tolerant FreeSWITCH deployment with active-passive clustering, database replication, and automated failover.

Editorial Team February 15, 2026 8 min read

For mission-critical call center operations, a single FreeSWITCH server is a single point of failure. High availability (HA) configurations ensure your call center stays operational even when hardware fails.

Why High Availability Matters

Business Impact of Downtime

Every minute of call center downtime means missed calls, lost revenue, and frustrated customers. For a 100-agent call center handling 500 calls per hour, even 30 minutes of downtime can result in hundreds of lost customer interactions.

SLA Commitments

Many call center operators have SLA commitments guaranteeing 99.9% or higher uptime. Achieving this requires redundant infrastructure with automated failover.

Clustering Strategies

Active-Passive Clustering

The most common HA setup for FreeSWITCH. One server handles all traffic (active) while a standby server monitors and takes over if the primary fails.

  • Primary server processes all calls normally
  • Standby server maintains synchronized configuration
  • Health monitoring detects primary server failure
  • Automatic failover switches traffic to standby within seconds
  • DNS or SIP proxy redirects new calls to the standby server
  • Active-Active with Load Balancing

    Both servers handle traffic simultaneously, with a SIP proxy (like OpenSIPS or Kamailio) distributing calls between them.

  • Higher total capacity (both servers share the load)
  • No wasted resources on standby
  • Requires external SIP proxy for load distribution
  • More complex to configure and maintain
  • Session persistence must be managed carefully
  • Database Replication

    Why Database Sync Matters

    FreeSWITCH stores configuration, CDR data, and runtime state in databases. Both servers must have access to identical data for seamless failover.

    Replication Options

  • PostgreSQL streaming replication: Real-time, synchronous replication between primary and standby databases
  • MySQL/MariaDB replication: Asynchronous or semi-synchronous replication for CDR and configuration data
  • Shared storage: NFS or distributed file systems for recordings and media files
  • Monitoring and Health Checks

    What to Monitor

  • FreeSWITCH process health and CPU/memory usage
  • Active call count and channel utilization
  • SIP registration status
  • Database connectivity and replication lag
  • Network connectivity between cluster nodes
  • Automated Failover Triggers

    Configure automatic failover when:

  • FreeSWITCH process crashes or becomes unresponsive
  • Server CPU exceeds 95% for more than 60 seconds
  • Network connectivity is lost for more than 10 seconds
  • Database replication lag exceeds acceptable thresholds
  • Best Practices

  • Test failover procedures regularly and do not wait for a real outage
  • Maintain identical FreeSWITCH versions and configurations on both servers
  • Use a separate monitoring network to avoid false failover triggers
  • Document your failover procedures and train your operations team
  • Keep automated runbooks for common failure scenarios
  • The Bottom Line

    High availability is not optional for production call centers. The cost of implementing clustering and failover is a fraction of the cost of unplanned downtime. Whether you choose active-passive for simplicity or active-active for performance, invest in HA before your first outage forces you to.

    Ready to Get Started?

    See our platform in action with a free personalized demo.

    Request a Demo