As the hosting operator, use PD AWS PostgreSQL’s customer graphs alongside your team’s application checks. Start with CPU utilisation and the time of the slowdown; a chart is evidence to investigate, rather than proof that a larger plan is automatically the answer.

Customer steps: open the service graphs

1. Open the active customer service and check its region and backing.
2. Choose Usage Graphs where your hosting business makes that section available.
3. Review CPU utilisation for the displayed period.
4. Compare the timing with the application’s slow requests and recent Activity.
5. Record the affected period and visible values before changing anything.

The charts request provider data when opened. They are not a promise of continuous live sampling. CPU is a percentage; storage, connections and memory use different units. Judge each displayed graph by its own label and scale.

Treat missing data separately

A new, stopped or unreachable database may have no usable recent series. A provider read or permission problem can also leave a graph empty. Do not interpret a blank graph as zero CPU, unlimited storage or no connections.

For Lightsail, if CPU appears but another series remains empty, your hosting team should check that metric independently against AWS. This guide does not promise every graph returns data on every installed build. RDS metrics require the applicable CloudWatch reads; Lightsail uses its separate database-metric permission.

Choose the next check

Sustained CPU load, connection pressure and storage exhaustion call for different investigations. Compare workload demand, instance class and application queries with the administrator before an upgrade. If the graphs load correctly but the application remains slow, continue workload diagnosis with your database administrator. Keep a failed graph read or display mismatch separate from an accurate high reading.

See the PD AWS PostgreSQL Blesta guide for related tasks, or explore PD AWS PostgreSQL.