The documented thresholds
SiteGround's knowledge base article on fair use explains that StartUp, GrowBig and GoGeek accounts live on shared servers, that a monitoring system watches CPU, RAM and disk I/O, and that red-flag values show what acceptable usage looks like. The article was last updated on 12 October 2021, so treat these numbers as SiteGround's most recent published guidance rather than a guarantee of current limits.
| Resource | StartUp | GrowBig | GoGeek |
|---|---|---|---|
| CPU seconds per hour | 1,000 | 2,000 | 4,000 |
| CPU seconds per day | 10,000 | 20,000 | 40,000 |
| CPU seconds per month | 300,000 | 600,000 | 800,000 |
| Memory per process | 768MB | 768MB | 768MB |
| Inodes per account (hard limit) | 200,000 | 400,000 | 600,000 |
| Database size | Up to 1,000MB | Up to 1,000MB | Up to 1,000MB |
Which threshold binds first
The three time windows do not scale evenly. On GrowBig, running at the hourly value all day would be 48,000 CPU seconds, more than double the 20,000 daily value, so the daily figure is the one that limits sustained use; the hourly figure limits spikes such as a live session or a cohort start. On GoGeek the monthly value of 800,000 averages about 26,700 a day, below the 40,000 daily value, so a GoGeek site that is busy every day can run into the monthly line first. On StartUp and GrowBig the monthly value is exactly 30 times the daily value.
Why course and membership pages use more CPU
SiteGround's CPU graph article defines an execution with an example: a visitor opening your site and loading the index file counts as one execution, and more visitors mean more executions. SiteGround's caching documentation says static content is served by NGINX Direct Delivery and full pages by Dynamic Caching, but that logged-in content is not cached by default. A public sales page served from cache costs almost nothing; a lesson page, progress update, quiz submission or account page for a logged-in student runs PHP and queries the database every time.
That is why a course site with modest visit numbers can use more CPU than a much busier blog. MemberPress's hosting guide also recommends making sure the register, thank-you, mepr, account, unauthorized and login pages are not cached on SiteGround, which is correct for function but adds uncached requests.
How to read the usage graph
SiteGround says the CPU statistics are in the Client Area under Services, Settings, Statistics, CPU Seconds. The graph can be viewed per hour or day and per website or for all sites. The graph shows CPU time in CPU seconds and, when that option is selected, the number of executions per hour.
- Pick your busiest day of the last month and note total CPU seconds against your plan's daily value.
- Switch to hourly and find the peak hour; compare it with the hourly value.
- Divide CPU seconds by executions for that hour. Example: 1,500 CPU seconds over 6,000 executions is 0.25 CPU seconds per request.
- If executions spiked but CPU per request stayed flat, you have more traffic; check whether it is students or bots.
- If CPU per request rose while executions stayed flat, something got slower: a plugin update, a report, a cron job.
- Check the per-website view if you host several sites on one plan; one site can consume the shared budget.
Worked example: what a daily threshold means in students
Using the method above, suppose your graph shows 0.25 CPU seconds per uncached request and a typical student session makes 40 uncached requests across lessons, quizzes and background calls. That is 10 CPU seconds per session. GrowBig's 20,000 daily value would then cover about 2,000 student sessions a day before counting any other traffic, and its 2,000 hourly value about 200 sessions in one hour. Halve the cost per request and you double both numbers, which is why optimization usually comes before an upgrade. These per-request and per-session figures are illustrative; use your own graph.
Checklist before you upgrade
- Confirm the spike is real traffic, not bots, brute-force login attempts or a stuck cron loop.
- Space cron jobs at least 30 minutes apart, as SiteGround's fair-use article recommends.
- Update or remove old plugins and themes; SiteGround notes inactive software can still start processes.
- Review slow database queries and keep each database under 1,000MB.
- Check inode count if you keep many backups or emails in the account; the inode limits are hard limits.
- Re-measure for a full week, including one launch or cohort day, before choosing GoGeek or Cloud.
- If you still exceed the values after fixes, compare GoGeek, SiteGround Cloud and a host with published PHP capacity.
Questions before you decide
What happens if I exceed SiteGround's CPU limits?
SiteGround's fair-use article says its system sends early warnings and that, in case of extreme or repeated overuse, it may limit access to the website until you take action.
Are the CPU limits still current?
The fair-use article checked for this guide shows a last update of 12 October 2021. Ask SiteGround support to confirm the values for your plan.
Does SiteGround count CPU seconds when a page is cached?
SiteGround does not state this directly in the pages checked. Its CPU graph article ties CPU time to scripts your account runs. Compare executions and CPU seconds on your graph before and after a caching change to see the effect on your own site.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- SiteGround KB: Fair use of server resources (page dated 12 October 2021) Accessed 29 Oct 2026
- SiteGround KB: CPU resource usage graph explained Accessed 29 Oct 2026
- SiteGround tutorial: Speed Optimizer caching settings Accessed 29 Oct 2026
- SiteGround shared hosting feature comparison Accessed 29 Oct 2026
- SiteGround KB: Fatal error maximum execution time exceeded Accessed 29 Oct 2026
- MemberPress docs: What web hosting works best with MemberPress Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.