10 hosting metrics to monitor in your dashboard (and what they mean)

You open your hosting control panel and find a wall of numbers: CPU, I/O, entry process, inode, MySQL connections. Unless you're a sysadmin, they're just cryptic acronyms until you hit a 508 or 503 error. Here we explain each one, with real thresholds from a public pricing list, so you can compare them with what you're seeing on your own account.

The metrics that matter

CPU (accessible cores): the processor quota assigned to your account. If the graph consistently sits above the limit shown in your panel, your site will slow down before any errors appear.

Memory/RAM: the total memory that processes within your account can use together. If you're consistently exceeding it—not just in isolated spikes—it's a sign your plan is undersized.

Disk I/O (KB/s): how much your account is reading and writing to disk per second. A value maxed out continuously will slow everything down, even pages unrelated to the script doing the writing.

Entry process: the most misunderstood metric. It's not the number of site visitors: it represents the number of simultaneous processes entering your account, and each PHP or CGI script executed by a user counts as one entry process. The limit exists for a specific reason: it was created to prevent DoS attacks against the web server, where all Apache connections are held up by hitting a slow page on the site. When the limit is exceeded, the web server responds with a 508 error page (Resource Limit Reached), not just a slowdown.

NProcs (process count): counts all processes on your account, not just PHP: cron jobs, SSH connections, email processes too. It's a broader limit than entry process and usually fills up less frequently.

Simultaneous MySQL connections: how many database queries your database can handle in parallel. If your site makes many database calls at once (heavy plugins, WooCommerce under load), this is the first metric to check before looking at I/O.

Inode (files and folders): often misunderstood as much as entry process. It doesn't measure space used but the number of objects on disk: disk space measures the amount of data, while inodes represent the number of files and directories. Email also consumes inodes: a mailbox with thousands of messages can hit the limit even with just a few MB used.

Bandwidth/traffic: the volume of data transferred outbound. On plans with "unlimited" traffic, still check for any fair use clause in your contract.

SMTP relay (hourly): the cap on emails you can send per hour. This fills up easily with newsletters or poorly configured automated notifications.

Disk space: the one metric almost everyone checks, but read it alongside inodes: a plan can have free space left while running out of inodes.

The real numbers from an official pricing list

To understand how these limits vary between plans, here's the official GoDaddy pricing table for cPanel hosting, checked on 15 October 2026 (Web Hosting (cPanel): accessible CPU cores 1, 1, 2, 2; RAM 512 MB, 1 GB, 1.5 GB, 2 GB; I/O 10,240 KB/s for all; entry processes 20, 30, 40, 50; NProcs 35, 45, 55, 65; file inodes 250,000 for all; disk space 25 GB, 50 GB, 75 GB, 100 GB for Economy, Deluxe, Ultimate and Maximum plans).

Plan	CPU	RAM	I/O	Entry process	NProcs	Inode	Disk
Economy	1 core	512 MB	10,240 KB/s	20	35	250,000	25 GB
Deluxe	1 core	1 GB	10,240 KB/s	30	45	250,000	50 GB
Ultimate	2 cores	1.5 GB	10,240 KB/s	40	55	250,000	75 GB
Maximum	2 cores	2 GB	10,240 KB/s	50	65	250,000	100 GB

Worth noting: all Web Hosting (cPanel) plans have a 500 SMTP relay cap per hour and 30 simultaneous MySQL connections, regardless of which plan you choose. The inode limit stays fixed at 250,000 across all four plans: it only increases if you upgrade to a Web Hosting Plus plan, where the highest tier reaches 2,000,000 inodes.

How to read these metrics in your control panel

In cPanel these values are found in the "CPU and Concurrent Connection Usage" section or "Statistics", depending on your panel version. If a graph consistently sits above the threshold (not just an isolated spike), restarting things won't fix it: either optimise the script consuming the resource, move to a plan with higher limits, or switch to a VPS where limits apply to the whole machine, not per account.