CPU warning email received on 6 November: “Your site has utilised over 50% of its daily resource limits — CPU warning.” The statistics panel later showed CPU usage above the displayed daily limit. This is a resource warning, not a confirmed site-error or suspension notice.
Other Information
My hosting account received a CPU warning on 6 November. The daily CPU graph shows usage above the displayed limit despite low daily hits. I have not identified an active backup or static-export job. Could you help identify which requests, scripts or processes are consuming CPU, or advise which logs are available for diagnosis?
Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look.
You probably can’t find out which requests or scripts are using the CPU. The CPU usage article says it’s only tracked for the account as a whole. Free hosting has no breakdown by time, domain, software or file, and no log you can use to narrow it down. A per-process breakdown exists only on premium hosting.
Here’s the article:
The article suggests comparing the CPU graph with your Daily Hits and Entry Process usage. If those are low, as you describe, code complexity is the main factor rather than traffic. In other words, each request is expensive, or something is running that isn’t a normal page view. The article’s suggestions are to remove unneeded scripts and plugins and to add caching.
What is textilesflow.com running: WordPress, another CMS, or custom PHP? If it’s WordPress or similar, which plugins are installed? That would show which of those suggestions is most likely to help.
The site runs WordPress. The same hosting account also contains a second WordPress installation under /pest-draft/.
Active plugins on the main site include Extendify, MonsterInsights, Imagify, JetBackup, Lazy Load, Loginizer, Loginizer Pro, Rank Math SEO, Really Simple Security, Simply Static, Site Assistant, WP Mail SMTP and WPForms Lite. LiteSpeed Cache and W3 Total Cache are inactive.
JetBackup shows no assigned backup schedule or recorded last run for its default job. Its queue shows completed maintenance tasks. Simply Static’s visible export log is dated October 30. Imagify shows 23 errors and no visible running optimisation.
Given these findings, what controlled troubleshooting sequence would you recommend? Is a supported page-caching configuration available for WordPress on free hosting? I want to avoid changing security, login or rewrite settings blindly.