API rate limiting is preventing access to services




Wordpress LScache Plugin: API rate limiting is preventing access to services

Last Updated on: Wed, 15 Apr 2026 00:00:02
Hello, I just logged in to a site I havent checked in a while to find that I have a huge backlog of tasks in the queue: 101 LQIP requests 12 Critical CSS requests ? last successful request was back in June! Cron is running fine for other tasks, so thats not the culprit. When I try to force cron manually I get a huge list of d/usage errors returned: Cloud Error: Please try after 2m 29s for service d/usage Logging into QUIC.cloud confirms that my API usage is at zero across all services this month for this domain. My website evidently hasnt been using the API, so why is it being rate-limited? Image optimisation requests are also being limited/refused, again, in spite of the fact my API usage is currently at zero. How do you identify hosts when applying rate limiting? Is it only by referring IP or by domain? I can imagine that if you are only using the server IP then this is going to rate limit users like me unfairly ? greedy neighbours on the same server are going to cause the IP to get limited all the time, which is unfair. Can we just go back to how things used to be? I much preferred using my own server to generate CCSS etc. It just worked, whereas this new system that externalises these processes onto your servers via API has consistently failed to work ever since it was introduced. Best wishes Hi, Apologize for the inconvenience. the 5 minutes limit is based on domain. Can we just go back to how things used to be? I much preferred using my own server to generate CCSS etc I am not sure what you are referring to ? the CCSS was always using our nodes to generate , since the day it was introduced. Best regards, Hi, Im going to mark this topic Resolved , due to lack of activity. If you still need help, please feel free to re-open it. Best regards, Hello, Thanks for your response and apologies for the delay, Ive been busy on client projects. Sadly, the same issue still persists, across different domains and servers. Cron tasks just never get seen of their own accord. Unless I manually intervene, the backlog remains static, month on month. Cron is set to run at 5 minute intervals, which according to the error messages Im seeing should be infrequent enough to not trip over the rate limits. Crontab has been fully tested, so I know it is executing WP-cron, which in turn is completing its tasks. How long should these processes take to complete? Sometimes even a modest request can take a minute or more, which leads me to suspect the process might be getting killed by the server. Does the CCSS use the same approach as image optimisation where it sends an optimisation request with the data to be optimised and then pulls it via cron once the cloud has completed? Update: in the course of testing whilst writing this post, I got a new error message: Failed to communicate with QUIC.cloud server: Unknown error: frequency_limit [server] https://node2.quic.cloud [service] lqip I am not sure what you are referring to ? I never looked under the bonnet of the plugin code but was under the distinct impression that CCSS and image placeholders were generated locally in early releases. I certainly never needed an API key and never ran into any rate limiting issues. Regardless as to how it was implemented it just worked, which is ultimately all Im yearning for. Back in those days I certainly remember that image compression was handled in the cloud and that could be a little patchy at times but once my domain had earned the trust of your servers things tended to go smoothly. Considering all the sites I manage are on the Enterprise tier, the fact that so very few API requests are being honoured (and none at all unless I manually nudge the queue) is surprising. Thanks for your help I forgot to re-open the ticket after my last reply! Please see above. Hi, Please create a ticket here , we will investigate it further Best regards,



LiteCache Rush: Speed comes from using less, not from doing it faster



Reference