As the hosting operator, you can give your customers PD AWS MariaDB usage graphs and use those readings alongside your team’s application checks. CPU, connections, freeable memory and free storage describe different pressures; use the timing and units to decide what needs investigation.

Customer steps: read the service graphs

1. Open the active customer service and confirm its database and AWS region.
2. Choose Usage Graphs after your hosting team has enabled that section for the offering.
3. Review CPU utilisation, Database connections, Freeable memory and Free storage for the displayed period.
4. Compare the graph timing with the application’s slow requests and recent Activity.
5. Keep the affected period and visible values before making changes.

The charts request RDS CloudWatch data when opened. They are not a promise of continuous live monitoring. CPU is a percentage, connections are a count, and memory and storage have their own displayed scales. Compare each graph with its normal range rather than treating all four as the same measurement.

Treat missing data separately

A new, stopped or unreachable database may have no usable recent series. A read failure or missing CloudWatch permission can also leave a graph empty. Blank data does not mean zero CPU, unlimited storage or no connections. As the hosting operator, check the database, region, selected period and provider read before changing the plan. If the section itself is absent, check the offering’s client controls.

Choose the next investigation

Sustained CPU demand, connection pressure and low free storage need different checks. Review workload demand, application queries and available capacity with your database administrator before deciding on an upgrade. If the graphs load correctly but the application is slow, continue those hosting-team workload checks rather than treating high usage alone as a module fault.

See the PD AWS MariaDB WHMCS guide for related tasks, or explore PD AWS MariaDB.