At Kinsta, we offer an uptime guarantee backed by our Service Level Agreement (“SLA”). Each site runs in a single Linux container, with the database running as a service within the site container. We do not run multiple load-balanced instances of each site. If you’d like to learn more, check out our article about our Kinsta architecture.
We monitor the uptime of all sites on our platform. If our monitoring detects that a site isn’t loading, our engineers respond quickly to get service restored to the site.
Some scenarios that may interfere with our uptime monitoring include:
- Password protection (basic authentication). If this is enabled, your site will return a 401 error to our monitor.
- Cloudflare’s Under Attack mode. This returns a 503 response to our HEAD request which interferes with monitoring.
- A site in maintenance mode (which can happen when running updates or if a maintenance mode plugin is enabled) may return a 503 response, which prevents monitoring.
- We can’t monitor non-WordPress sites.
- Bot blocking service or plugin. If you block all bots or if you’ve blocked our kinsta-bot user agent, our monitor will receive a 406 response code and won’t be able to monitor the site.
- If either our uptime monitor’s IP address(es) or origin country (geo-blocking) is blocked, this will prevent monitoring. If you activate these features on Kinsta’s servers, we can add exceptions so our monitor won’t be blocked.
- Custom caching rules and configurations at CDN, proxy, or security services may cause issues. Caching everything, including Kinsta’s query string HEAD request, will interfere with our monitoring.
- Sites with reverse proxy setups where the primary domain isn’t redirecting to the target URL can’t be monitored.
- Sites where the primary domain doesn’t resolve to the install/site it’s been added to, or if it redirects to another domain in the same domain list can’t be monitored.