How to Use MyKinsta Analytics to Troubleshoot Issues on Your Site

It can sometimes be frustrating when you realize you don’t have enough access to data to troubleshoot issues on your WordPress site. Thankfully, with the new revamped MyKinsta Analytics you can now investigate and diagnose a lot of these problems from right within the dashboard. Today we’ll dive into each section of MyKinsta Analytics and share some examples (and real-world scenarios) of how you can take advantage of these new reports to improve and fix your WordPress sites. Find out what’s going on under the hood!

Diving Into MyKinsta Analytics

The main dashboard of MyKinsta has a few quick insights into your resource usage, as well as data transfer and unique visits. To dive into the more in-depth reports you will want to click on “Analytics” on the sidebar.

At the top you can filter the stats individually or view data for all of them combined. You can then choose to see data for the past 24 hours, 7 days, or 30 days.

MyKinsta Analytics has been split up into six different sections of which we will dive into each further below:

• Resources
• Dispersion
• Performance
• Response
• Cache
• Geo & IP

1. Resources

Under the resource usage section, you can view your total number of visitors, bandwidth usage, total requests by bytes, and total requests by visits.

Visitors

The visitor’s report lets you see the total number of people that have visited your WordPress site. If you highlight a specific point in time on the graph it will show you some comparison statistics, such as the total number of visitors being higher than the previous day, etc. This is the exact number of visitors to the web server. Remember, that your Google Analytics filters and rules won’t work here. In case you’d like to know the number of human visitors of your site, all services will show a different number based on their own set of rules — who they consider to be irrelevant/bot traffic and those that they don’t.

Kinsta’s hosting plans are based on the total number of visitors to your site. Read more about how Kinsta counts visitors. Note: Your total visits count in the resources section might differ from the total you see on your main MyKinsta dashboard. This is because the MyKinsta dashboard shows visits within your current billing cycle.

Bandwidth Usage

The bandwidth usage report shows the total data your site has used. Kinsta charges for plans based on the number of visitors to your site, but bandwidth usage can help you troubleshoot performance issues. If you highlight a specific point in time on the graph it will show you some comparison statistics, such as the total being lower than the period average, etc.

We strongly recommend every customer to implement a CDN. Not only because you’ll see an increase in speed, but this can be a great way to decrease bandwidth and resources on your site. CDN bandwidth is very cheap or even free. Check out our in-depth post on the benefits of a WordPress CDN and why you should use one. Or if you’re ready, check out how to enable the Kinsta CDN on your site.

Top Requests by Bytes

A byte is a sequence of binary bits in a serialized data stream in data transmission systems. When it comes to your WordPress site, this is typically measured in MBs, GBs, and TBs. The total number of bytes transferred on your site make up your bandwidth. In the top requests by bytes report, you can see exactly which requests on your site are using up the most bandwidth.

Top Requests by Count

The top requests by count report shows you the most requested resources from your site on the server. Using this report and the ones above can help you troubleshoot and figure out where your bandwidth is going. A lot of times you can easily spot a pattern.

2. Dispersion

Under the dispersion section, you can view different insights about traffic on your site.

Mobile vs Desktop

The mobile vs desktop report allows you to see which devices are hitting your site. In this example below, you can see that it is primarily desktop traffic at over 86%.

3. Performance Monitoring

Under the performance monitoring section, you can view your average PHP + MySQL response time, PHP throughput, AJAX usage, top average upstream time, and top maximum upstream time.

Average PHP + MySQL Response Time

Whenever you visit your WordPress site, PHP and MySQL are used to compile and query the data you see on the page. This chart shows you the average response time of the PHP engine and the MySQL engine for every non-cached dynamic request. Knowing these response times can help you troubleshoot slowness. If you are seeing huge spikes here, feel free to open up a support ticket with our team.

PHP Throughput

Throughput indicates the number of transactions per second an application can handle, and in this report, it is referring to PHP throughput from your WordPress site. In other words, it shows you how many times a PHP asset was requested.

AJAX Usage

AJAX is a client-side script that communicates to and from a server/database without the need for a postback or a complete page refresh. When it comes to WordPress, a lot of you have probably seen this in your speed tests. The top two issues with AJAX include plugins causing it to spike and CPU issues on the back-end. Make sure to check out our in-depth post on diagnosing high Admin-AJAX usage on your WordPress site.

The AJAX usage report in MyKinsta analytics can be a great way to help you troubleshoot these types of issues as you can see if you are seeing certain AJAX spikes during certain periods. This chart shows the count of the admin-ajax requests. You can then utilize some of the tips in the post we mentioned above to narrow down where they might be coming from.

Top Average Upstream Time

Upstream time is the total time taken for NGINX (and upstream servers) to process a request and send a response. Time is measured in seconds, with millisecond resolution. Read more about NGINX metrics. This list shows the top average PHP and MySQL response times (combined) for your requests.

Top Maximum Upstream Time

This list shows the top response times from PHP and MySQL. Please note, that these numbers can be one time peaks, it’s suggested to compare this list with “Top Average Upstream Time.”

4. Response

Under the response analysis section, you can view your response code breakdown, response stats, 500 error breakdown, 400 error breakdown, redirect breakdown, and top 404 errors.

Response Code Breakdown

The response code breakdown report lets you see an overview of the distribution of HTTP status codes served for the requested resources. Response codes, also known as HTTP status codes, are not always bad. For example, a 200 HTTP status code means that “Everything is OK.” This is the code that is delivered when a web page or resource acts exactly the way it’s expected to. We’ll go into the others further below.

Response Stats

The response stats report lets you see the total number of redirects happening, errors, success rate, and error ratio. Every WordPress site will typically have a small error rate ratio, this is completely normal.

500 Error Breakdown

The 500 error breakdown report shows you the total number of 500 errors that occurred on the server.  Here is a more in-depth explanation of what each of these means:

• 500: “There was an error on the server and the request could not be completed.” A generic code that simply means “internal server error”. Something went wrong on the server and the requested resource was not delivered. This is the code generated by WordPress when the connection to the database breaks. Make sure to check out our in-depth article on how to fix the error establishing a database connection.
• 502: “Bad Gateway”. This error code typically means that one server has received an invalid response from another. Sometimes a query or request will take too long and so it is canceled or killed by the server. Read more about why a 502 bad gateway error occurs.
• 503: “The server is unavailable to handle this request right now.” The request cannot be completed right now. This code may be returned by an overloaded server that is unable to handle additional requests.

400 Error Breakdown

The 400 error breakdown report shows you the total number of 400 errors that occurred on the server. Here is a more in-depth explanation of what each of these means:

• 401: “Unauthorized.” This is returned by the server when the target resource lacks valid authentication credentials.
• 403: “Access to that resource is forbidden.” This code is returned when a user attempts to access something that they don’t have permission to access. For example, trying to view password-protected content without logging in might produce a 403 error.
• 404: “The requested resource was not found.” The most common error message of them all. This code means that the requested resource does not exist and that the server does not know if it ever existed.
• 405: “Method not allowed.” This is generated when the hosting server (origin server) supports the method received, but the target resource doesn’t.
• 429: “Too Many Requests.” This is typically generated by the server when the user has sent too many requests in a given amount of time (rate limiting). A lot of times this could happen from bots or scripts trying to brute-force their way into your default WordPress login page. You can help lock down your site by changing your WordPress login URL.
• 499: “Client closed request.” This is returned by NGINX when the client closes the request while NGINX is still processing it.

Redirect Breakdown

The 300 error breakdown report shows you the total number of 300 errors that occurred on the server. Remember, that like 200 response codes, not all errors are bad. 300 errors typically mean you have simply moved the content elsewhere. 301 redirects, for example, are very important as they will help retain your SEO rankings for URL and site changes. Here is a more in-depth explanation of what each of these means.

• 301: “The requested resource has been moved permanently.” This code is delivered when a web page or resource has been permanently replaced with a different resource. It is used for permanent URL redirection.
• 302: “The requested resource has moved, but was found.” This code is used to indicate that the requested resource was found, just not at the location where it was expected. It is used for temporary URL redirection.
• 304: “The requested resource has not been modified since the last time you accessed it.” This code tells the browser that resources stored in the browser cache haven’t changed. It’s used to speed up web page delivery by reusing previously downloaded resources.

Top 404 Errors

The top 404 errors report helps you more easily troubleshoot the most requested resources that visitors or bots are hitting that no longer exist on your site.

If you’re seeing a large amount of 404 errors, it is recommended that you go through your site and fix them for SEO and usability purposes. You can also look them up in Google Search Console under crawl errors.

5. Cache Analysis

Under the cache analysis section, you can view your cache component stack, total cache bypasses, and cache component chart.

Cache Component Stack

Whenever a file or resource is requested from Kinsta’s servers it sends a value in the HTTP response header (X-Kinsta-Cache) to let you know the status of the cache.

There are four types of cache response headers returned:

• HIT: A HIT means that the resource is being served from the cache on Kinsta’s servers. Typically this is what you want to see.
• BYPASS: This means that there is probably a rule or conflict that is preventing the resource from caching. We have rules in place so that certain things on your WordPress site don’t cache. For example, your /wp-login.php page is one. This is to ensure proper functionality when you log in to your dashboard.
• MISS: This means that the content was not yet in the cache but will be after the first request. The second request to that file will be a cache HIT. Remember that each time you purge the cache on your WordPress site that it has to rebuild by people visiting it. This is why we recommend not clearing entire cache constantly. The Kinsta cache plugin automatically purges only certain sections of your site so that the rest can remain cached. Read more about how Kinsta handles caching.
• EXPIRED: This means the cached content has expired and the new content from the hosting server has been fetched.

The cache component stack report lets you see the total number of response header values that have been generated from your site.

Cache Component Chart

The cache component chart is again another way to view your total cache requests.

Top Cache Bypasses

The top cache bypasses report lets you see some of the top requests that are bypassing the cache on Kinsta’s servers. It is good to take a look at this and ensure they should be. In this example below, we can see that the OneSignal push notification plugin has a few files that are bypassing the cache. Because of how the plugin works, this is actually OK. We can also see that /wp-cron.php isn’t cached, which again, shouldn’t be.

6. Geo Analysis & IP

Under the Geo analysis section, you can view your top countries, top regions, top cities, and the top IP address visiting your site.

Top Countries

The top countries report can be one good way to determine where you should be placing your WordPress site. This is a geo analysis by country of the requests from visitors IP addresses.  In this example below, the site should probably be placed on a server in the United States, since a majority of the traffic is from there. Make sure to read our in-depth post about network latency and why it’s important to strategically place your site. Kinsta now has 15 Google Cloud Platform locations around the globe where you can host your WordPress site.

Top Regions

Geo analysis by region of the requests from visitors IP addresses.

Top Cities

Geo analysis by city of the requests from visitors IP addresses.

Top Client IPs

The top client IPs report can be very helpful if your site is suddenly generating a lot of bandwidth or getting hit by bots. This shows the top IP addresses, listed by request count.

How can you use this data? Well, we recently did a case study on a small e-commerce WordPress site. Analyzing the top 10 client IPS for the last 7 days to the site instantly showed some suspicious activity. A majority of them had over 10,000 requests, and there were quite a few. It was most likely a DDoS or brute force attack. You can always rely on Google to provide you with data. Entering in a couple of the top IPs into search, we could easily see that most of them were all proxy addresses, meaning someone was most likely wanting to hide their traffic.

The next step in this scenario that we would recommend is either reaching out to the Kinsta team to block the IPs for you, or considering a web application firewall like Cloudflare or Sucuri. You can check out our case study in which Sucuri instantly blocked all this bad traffic.

Additional Notes

Full log data in regards to analytics is retained for 30 days. We suggest checking the dashboard and analytics section more frequently after first migrating to Kinsta. If you see an unexplained traffic spike or inconsistency which has you concerned, let our team know and we can further investigate the logs for you to help determine the cause.

With all of the data above, hopefully, now you have a better understanding of how Kinsta is actually delivering content to your visitors.