Articles Tagged: availability

The recommended way to monitor any type of database, including Microsoft SQL Server, is to create a hidden web-page that does a specific database query, and when successfully completed, sends a word (e.g. “OK”) to the web browser. This method is secure because you need not open SQL ports in your firewall to allow our […]

Yes, absolutely. This is a very common use for our DNS Failover service. While some customers use it to switch between servers at different datacenters, it works very well to switch between the same server that has two different public IP addresses at the same location or datacenter (e.g. two ISPs, two WAN connections etc.) DNS […]

Total Uptime offers a 100% network uptime for all customers for all of our solutions. That means we promise it will always be available. Period. Many challengers will state that since 100% uptime is impossible to achieve, it is foolish to make such a promise, but we strongly disagree. If we only set out to […]

We do not have any specific network or datacenter maintenance windows. Avoiding downtime on our global Cloud Platform is our highest priority, so we always make every effort to perform maintenance in such a way as to prevent customer impact. That’s why you rarely receive datacenter maintenance notifications from us. In most cases, we can […]

Search our Knowledge Base

About Total Uptime Technologies

Total Uptime Technologies, LLC is a privately held provider of Cloud solutions designed to help organizations achieve high availability in a demanding online world. Our multi-datacenter, multi-country Cloud platform easily delivers on our uptime promise because it has been engineered from the ground up to be fast, flexible and resilient.

While other organizations were busy renaming their legacy solutions as “Cloud” and dressing them up to take advantage of the latest hype, Total Uptime Technologies was engineering a true Cloud Platform that was multi-datacenter at its core. In our mind, Cloud meant resilient, and resilient meant that we had to design an application that could span infrastructure at different datacenters in different geographies – continents apart. Only then would we be content with calling it “Cloud”.