- This topic has 3 replies, 2 voices, and was last updated 1 month, 2 weeks ago by
.
-
Posts
-
Hi,
We have had a steady stream of warnings over several weeks from Kinsta about 500 errors. Here is what they look like, and seem to be related to the Statistics.
fmsb.com 199.116.170.123 [14/Apr/2026:12:14:53 +0000] POST “/wp-json/ajax-search-pro/statistics/interaction/add” HTTP/2.0 500 “https://fmsb.com/publications/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36 Edg/146.0.0.0” 199.116.170.123 “/index.php” – – 538 0.329 0.328
We’re running the latest plugin version.
We have not provided access details for now, because we do not want to add new users unless absolutely needed.
Could you advise what may be causing this?
Thank you.
Hi David,
The only thing visible from this log is that the interaction registration when clicking on a search result fails for some reason.
Are there any more detailed logs in the PHP error log on this by any chance? Error 500 is very generic, usually it is returned by the server when there is a fatal error during script execution and is usually logged in the PHP error log with exact details revealing the exact problem.
Hi Ernest,
We chatted with Kinsta about this because we could not find further info in their error logs. Here is what they said.
“When a POST request is used, unlike GET, there is data being exchanged between the server and the browser (eg: some parameters will be sent to that URL, a good example of a type of page that would use POST instead of GET is a contact form, where the message would be sent in the POST request). So it could also be due to the contents of the POST request, as the script (in this case /wp-json/ajax-search-pro/statistics/interaction/add) may have received data that it doesn’t know what to do with, and in this case, a generic 500 error would be displayed. I have tried to access the URL from where that request was generated (/publications/ according to the log entry), and I tried to search for “test search” and didn’t get any errors, so this could indeed have been due to a request with either incorrect or malformed data, which the target script wasn’t able to process.”
When we asked if there was any more detailed info available:
“Unfortunately not, I do not see anything in the error log related to this. Your WordPress’ installation’s debug.log is also not showing anything related to that specific request (you can confirm this in the /wp-content/debug.log and debug.log.1 files). So it does look like it was something malformed, maybe from a bot/automated request.”
We’re sorry that there isn’t more that I can provide.
Hi,
Okay, thank you for the information.
All right, so if there is nothing in relation in the error log, then those might be bfrom botted/automated requests as they suggested, which have been caught in the firewall but still flagged as “internal server error 500”. There is also a defense try->catch statement around the handler, which will signal an error state when malformed data is sent, so the server doesn’t have to deal with it. However that would be logged in the error log for sure, so I am guessing it is the automated requests.
For now you can safely ignore it in my honest opinion, there is no sign of any serious issue behind it. If it comes back regularly, then let me know. In that case I will have to do an in depth code debugging via (s)FTP to try to re-create the problem.
- You must be logged in to reply to this topic.