Skip to content Skip to sidebar

Home › Support › English Support › [Closed] The website is sending a lot of GET requests to /wp-json/wpml/v1/rest/status

[Closed] The website is sending a lot of GET requests to /wp-json/wpml/v1/rest/status

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 13:00 – 18:00 -
- 20:00 – 23:00 20:00 – 23:00 20:00 – 23:00 20:00 – 23:00 20:00 – 23:00 -

Supporter timezone: Asia/Singapore (GMT+08:00)

This topic contains 9 replies, has 0 voices.

Last updated by Kor 4 months, 2 weeks ago.

Assisted by: Kor.

Author Posts
December 7, 2025 at 9:53 pm #17642539

Peter

Hi,

I just recognized, that the CPU workload is very high on this website and I see, that a lot of non-cached requests are causing this issue:
GET /wp-json/wpml/v1/rest/status?test_get_parameter=1&cachebuster=1765141033

Screenshot of a part of the log:
hidden link

What are these requests, why are there so many and how can I disable, block or stop these requests?
December 8, 2025 at 9:19 am #17643138

Kor

Thanks for your reply.

I need to check your Website's debug information before we investigate this further. I've enabled a private message for submitting the debug information for this support ticket. Please follow these initial debugging steps:
https://wpml.org/faq/provide-debug-information-faster-support/
In short:
- Go to "WPML > Support > Debug Information" (link)
- Copy the Debug Information from there.
- Find the private field I activated and paste that information.
December 10, 2025 at 9:07 am #17650679

Peter

I have pasted the debug info.

FYI: I have added a firewall rule, that is blocking these requests now. The WPML is now showing a notification about this blocking, but it is "normal" with the current setup.

I will enable this request once we find a solution for my current issue.
December 10, 2025 at 1:36 pm #17652451

Kor

Thanks for your reply. I will require temporary access (WP-Admin and FTP) to a test site where the problem has been replicated, if possible. This will enable me to provide better assistance and determine if any configurations need to be modified.

Please note that it is important to have a backup for security purposes and to prevent any potential data loss. You can use the UpdraftPlus plugin (https://wordpress.org/plugins/updraftplus/) to fulfill your backup requirements.

Your upcoming reply will be treated with confidentiality and will only be visible to you and me.

✙ To resolve the issue, I may need your consent to deactivate and reactivate plugins and the theme, as well as make configuration changes on the site if necessary. This emphasizes the significance of having a backup.
December 12, 2025 at 1:02 pm #17659278

Kor

Thanks for your reply. Could you let me know where I can view the error logs? I need to compare the logs before and after WPML is activated so I can file a report if I’m unable to determine the cause of the issue.
December 14, 2025 at 12:12 am #17661770

Peter

You can't see the log, it's a server log, where I can see all no-cache requests:
hidden link

Here you can see the CPU resources before the block and after the block:
hidden link
December 14, 2025 at 4:43 pm #17662241

Kor

Thanks for your reply. Could you share some exported reports here so that I can escalate this to our 2nd Tier Support for further investigation?

December 17, 2025 at 11:43 am #17670767

Peter

I can not export the log, but you can use the screenshot, that I have already shared.
December 17, 2025 at 12:11 pm #17670807

Kor

Thanks for your patience. I will share this with our 2nd Tier Support and I will come back to you once I've feedback.

December 19, 2025 at 6:04 pm #17678869

Kor

Thanks for your patience while we investigated this further.

This is the feedback from our 2nd Tier Support. After checking this in detail, we could not find any issues on the WPML side. To confirm this, we ran several tests to understand how and when the /wp-json/wpml/v1/rest-status endpoint is triggered.

We tested this on a staging site and monitored the requests using a debugging tool. The endpoint is only called when visiting WPML → Support in the WordPress admin. After that, it is called again only once every 10 minutes, and only if you are actively browsing WPML admin pages and a system cache (called a transient) has expired. If you refresh other WordPress admin pages, no additional calls are made during that 10-minute window.

We also double-checked this behavior directly in the code, and it behaves exactly as expected.

Based on these findings, the issue does not appear to be caused by WPML itself. To help us pinpoint what is happening on your production site, could you please try the following:

  1. Install the Query Monitor plugin on your production site, enable HTTP API Calls, and record a short screen recording showing which WordPress admin page triggers the repeated calls to:
    /wp-json/wpml/v1/rest-status
  2. Check whether something on the production site (such as another plugin, a cron job, or hosting-level cache rules) is clearing WordPress cache data too frequently. In particular, please verify that the cache entry named _transient_timeout_wpml_requirements:

    • Is being created correctly
    • Updates approximately every 10 minutes
    • Is not being deleted or overwritten unexpectedly

If this cache entry is being cleared repeatedly, it would explain why the endpoint is being called more often than expected.

Once we have this information, we will be happy to continue investigating with you.

The topic ‘[Closed] The website is sending a lot of GET requests to /wp-json/wpml/v1/rest/status’ is closed to new replies.