Site redundancy # Peering between sites Two independent installations at different sites work as one cluster. Each has its own database and exchanges changes directly over HTTPS. An available site keeps receiving events if monitoring sends them to its address. ## How it works - **Each site has its own PostgreSQL database**There is no single shared database as a common point of failure. Installations exchange changes directly. - **A leader processes events**Other sites forward writes to the leader. If it becomes unavailable, an available site takes over processing. Failover time depends on the network and should be tested in your environment. - **Sites work independently during a network partition**Both keep accepting alerts. When connectivity returns, changes are reconciled and duplicate records are merged. - **The phone switches automatically**The app knows the site addresses and chooses one it can reach without manual intervention. ## When to use it ### Alerting should survive a site outage If your alerting system lives in the same cluster as your services, a site failure can take down both the services and the way you hear about it. ### Use a second site If you have a backup data center or a second availability zone, run another Acktide installation there. Test network reachability, the signal source and recovery separately. Configure this under Settings → Sites. Enable peering on the first site, add a second site, then enter the one-time token during initial setup of the new installation. Peering is available in Free and Enterprise. Backup sites within one organization’s agreed environment do not require separate licenses. [Pricing](https://acktide.com/en/pricing.html) [Backup alert channel](https://acktide.com/en/backup-channel.html) ## Requirements and limits Monitoring must send events to both sites. Detecting an entire site outage requires a signal source outside that site. The phone needs access to at least one server. During a network partition, both sites may operate at once and duplicate notifications can occur. There is no quorum. Peering does not replace backups. If a site is offline longer than the change-log retention period of 7 days, a full resync may discard local changes that never reached its peers. Sites in one cluster serve one workspace and trust each other. Peering does not merge independent clients into one organization. [Test delivery before your shift →](https://acktide.com/en/delivery-check.html)