High availability
Keeping your Exo workloads available and knowing when something needs attention.
We manage the Exo control plane and its database. Your team looks after the Operator, Agent pods, networking, and storage in your clusters.
In this reference design, PostgreSQL streams its write-ahead log (WAL) from the primary to the standby, which replays it to stay up to date.
What your team manages
Use nodes across availability zones and leave spare capacity for upgrades or a failed node. The Operator runs as one pod by default, so a restart can interrupt connections. Test that your storage can recover in another zone.
Monitoring your cluster
Use your existing Kubernetes monitoring. With Prometheus, collect pod state from kube-state-metrics and CPU/memory usage from kubelet/cAdvisor. Check which volume-usage metrics your storage backend exposes.
| Watch for | Where to look |
|---|---|
| High CPU or memory use | Cluster monitoring: check Agent demand and available capacity. |
| Restarts or pods stuck Pending | Pod state and Kubernetes events: check limits, image access, and capacity. |
| Lost connection to Exo | Exo Deployments page and Operator logs: check network access and credentials. |
| Storage running low | Volume usage and backup reports: expand space and check backups. |
For Operator metrics, add autonomic-manager in autonomic-system to your private monitoring: port 8080, path /metrics. The chart does not install dashboards or alerts. A Ready pod does not confirm a connection to Exo. Check deployment status and logs.
kubectl -n autonomic-system logs deployment/autonomic-manager --tail=50
Assign an owner to each alert. If your cluster and network are healthy but Exo is still unreachable, contact Exo support. See connection troubleshooting.