On a clustered setup, a failed server does not have to be your outage
On a clustered setup, a fully synced clone runs in parallel and traffic moves to it automatically if the primary stops answering.
Most hosts run your site on one machine
If it falls over during your launch, you are offline until someone notices. That is the part the uptime percentage on the sales page does not tell you.
Our clustered setups run a fully synced clone in parallel, behind a load balancer, so a failed machine does not have to become your outage.
It matters most where downtime cuts off paying members mid-session, on MemberPress, MemberMouse and LearnDash sites.
How failover sync works on a clustered setup
Clone
A fully synced clone of your site runs in parallel with the primary. Same site, same data, already warm rather than waiting to boot.
Balance
A load balancer sits in front of both machines. If the primary stops answering, traffic goes to the clone instead.
Reroute
DNS routes traffic to the clone, so recovery does not wait on someone being paged at 3am. UptimeRobot checks from the outside and alerts us either way.
The technology behind it
Server architecture we manage ourselves
Sites run in virtual machines on bare metal servers from data centre partners, on hardware we specify. On that infrastructure we run our own LiteSpeed Enterprise-based stack, rather than reselling someone else's platform.
- A LiteSpeed Enterprise-based stack, tuned per site
- Single node, or clustered where failover sync applies
- Deployed in the geography you need
UptimeRobot
UptimeRobot checks the site from outside our own network and alerts us when a check fails.
- External checks, independent of our servers
Cloudflare
The layer that actually moves your traffic when it matters.
- Load balancing
- Reverse Proxy / CDN
- Custom rules and workers
Stop finding out about downtime from your members
Talk to us about what your site does when a server dies, or start with a free site speed audit.