At Kinsta, whilst we do not offer high availability (HA) hosting, we do offer a Service Level Agreement (SLA) backed uptime guarantee. At Kinsta, every site on our platform runs in a single Linux container, and the site database runs as a service within the site container, all built on Google Cloud Platform (GCP) and Cloudflare. We do not run multiple load-balanced instances of each site infrastructure.
For more details about our infrastructure and architecture, see:
- Application and Database Hosting infrastructure
- Static Site Hosting infrastructure
- WordPress Hosting infrastructure
Thanks to the flexibility afforded by the use of a container-based infrastructure, proactive load management by our Engineering team, and the use of a best-in-class cloud provider in Google Cloud Platform, we are able to offer an SLA-backed 99.9% uptime guarantee.
Kinsta’s maintenance period is each day, Monday through Sunday, from 2 am to 5 am local time, based on the time zone of the data center in which each application is hosted. We do not send monitoring notifications if maintenance is performed during this time. For more information, refer to Kinsta’s Service Level Agreement.
Circumstances That Block Uptime Monitoring
In order to ensure we meet our uptime guarantee, we monitor every site on our platform for uptime. When one of our uptime monitors fails, our Engineers respond immediately and work to restore service to the site. However, there are a few scenarios where our ability to monitor uptime may be limited:
- If you have basic authentication enabled, this will serve a 401 error to all unauthorized requests.
- Cloudflare’s I’m under attack mode has a 5-second wait time to prevent DDoS attacks. This doesn’t apply to HEAD requests, as those will respond with a 503 error.
- Reverse proxy sites where the primary domain isn’t redirecting to the target URL.
- Certain instances of custom caching can cause issues. For example, if you cache Kinsta’s query string HEAD request. Proxy services such as Sucuri and Cloudflare can also sometimes cause issues with caching, depending on the configuration.
- Bot blocking service: Our uptime monitor uses the
kinsta-botas a user-agent, so if you block it with a plugin or service (user-agent deny) this can cause our uptime monitoring to fail (this typically results in a 406 response code).
- Blocking either our uptime monitor’s IP address(es) or origin country (Geo-block) will impact our monitoring. If you configure these features on Kinsta’s servers it’s not an issue since we add exceptions.
- If the primary domain doesn’t resolve to the install where it’s added or it has a redirect to another domain (listed in the same site’s domain list).
- When a site is in maintenance mode, it might return a 503 response.