|5||Qube Managed Services||Linux||0:00:00||0.009||0.131||0.057||0.116||0.116|
|6||XILO Communications Ltd.||Linux||0:00:00||0.009||0.205||0.063||0.126||0.126|
|7||Kattare Internet Services||Citrix Netscaler||0:00:00||0.009||0.498||0.117||0.230||0.231|
|8||New York Internet||FreeBSD||0:00:00||0.013||0.552||0.037||0.077||0.297|
Pair Networks had the most reliable hosting company site in June, with only one failed request. Pair Networks was founded in 1995, putting it among the oldest web hosting companies. Its custom-built data centre is based in Pittsburgh, where it provides a range of premium hosting services.
In second place this month, Netcetera also had just one failed request but with a slightly longer average connection time. Netcetera provides carbon-neutral shared, dedicated, and cloud hosting from its Dataport data centre on the Isle of Man, and recently partnered with vCita LiveSite to offer document sharing, appointment scheduling and online payments.
With two failed requests, Lightcrest took third place. Lightcrest operates its cloud services using its own Kahu Compute Fabric infrastructure, without outsourcing any components to third-party cloud providers. Since Netcraft began monitoring its site in September 2014, Lightcrest has maintained a 99.97% uptime record.
Four of June’s top ten hosting company sites ran on Linux operating systems, with a further three using FreeBSD. Also appearing were Citrix Netscaler and SmartOS, powering one site each. Windows operating systems have now been absent from the top ten for a full year, last appearing in June 2015.
Netcraft measures and makes available the response times of around forty leading hosting providers’ sites. The performance measurements are made at fifteen minute intervals from separate points around the internet, and averages are calculated over the immediately preceding 24 hour period.
From a customer’s point of view, the percentage of failed requests is more pertinent than outages on hosting companies’ own sites, as this gives a pointer to reliability of routing, and this is why we choose to rank our table by fewest failed requests, rather than shortest periods of outage. In the event the number of failed requests are equal then sites are ranked by average connection times.
Information on the measurement process and current measurements is available.