Visitors get a plain page: "Resource Limit Is Reached. The website is temporarily unable to service your request as it exceeded resource limit. Please try again later." Nothing is broken in WordPress itself. Your shared hosting account has a cap on CPU, memory and how many requests it may run at once, and the site went over it, so the host is turning visitors away until the load drops. Here is how to find what is using it up, and the fix for each case.
What the visitor sees
harborbakery.example/
What the checks found
Find out which limit, and who is using it
Open cPanel > Resource Usage (some hosts call it CPU and Concurrent Connection Usage). It lists each time a limit was hit: EP (entry processes, requests running at once), CPU, PMEM (memory) or NPROC. EP faults mean too many requests at the same moment; CPU or memory faults mean each request is too heavy.
Open cPanel > Raw Access or Awstats for the hour the faults started. Sort by address and by page. Hundreds of hits from one address or one crawler, or a flood of POST /xmlrpc.php or POST /wp-login.php, is the whole answer in most cases.
Look for wp-cron.php and admin-ajax.php in the same log. A call to either on nearly every page view means WP-Cron runs on visits, or an open dashboard tab is polling through the Heartbeat every few seconds.
Did it start after adding a plugin (a page builder, a stats plugin that logs every visit, a broken-link checker, a backup plugin running in the day)? Note the date in Resource Usage against the plugin's install date.
Check whether pages are cached. Load the home page, open F12 > Network, click the first request. No cache header at all means every visitor runs PHP and the database from scratch.
The fixes, by case
A bot or crawler flood: block the address in cPanel > IP Blocker, or rate-limit bots at a free Cloudflare plan ("Bot Fight Mode", or a rule for the user agent). Aggressive SEO crawlers can also be told to slow down or stay out in robots.txt.
xmlrpc.php or wp-login.php attacks: if nothing you use needs XML-RPC (the Jetpack app and a few posting tools do), deny it in .htaccess with <Files xmlrpc.php> Require all denied </Files>. Limit login attempts with a security plugin, or put the login behind Cloudflare.
WP-Cron on every visit: add define('DISABLE_WP_CRON', true); to wp-config.php, then in cPanel > Cron Jobs run wget -q -O - https://harborbakery.example/wp-cron.php?doing_wp_cron >/dev/null 2>&1 every 15 minutes, with your real address.
Heartbeat polling: close dashboard tabs you are not using, and slow the Heartbeat to 60 seconds with a small plugin such as Heartbeat Control.
No page cache: turn on the host's own cache (LiteSpeed Cache on LiteSpeed hosts) or a caching plugin. Cached pages are served without PHP, so the same visitors use a small part of the limit.
One heavy plugin: deactivate it and watch Resource Usage for a day. Replace it, or schedule its job (backups, link checks, imports) for the night.
Real growth: only when the site is cached, the bots are blocked and the faults still come at busy hours, ask the host for more entry processes or move to a bigger plan.
What you see, what it means, what it needs
What you see
What it means
Usual fix
EP faults, one address with hundreds of hits
A bot or crawler is flooding the site
Block it, Cloudflare bot rules
Many POST /xmlrpc.php or /wp-login.php
Password-guessing attack
Deny xmlrpc.php, limit logins
wp-cron.php on almost every page view
Scheduled tasks run on visits
DISABLE_WP_CRON plus a server cron job
CPU or memory faults, no cache header
Every visit runs PHP and the database
Turn on a page cache
Faults began the day a plugin was added
That plugin is too heavy for the plan
Replace it or run its job at night
What not to do
Do not buy a bigger plan first. If a bot is the cause it will fill the bigger limit too, and you pay more each month for it.
Do not keep reloading the site to see if it is back. Every reload is another request against the same limit.
Do not install several "speed" plugins at once. Two caches fight each other and can add load instead of removing it.
Keep a copy of wp-config.php and .htaccess before editing them, so every change can be undone.