Is your website slowing down or reaching an account resource limit? A useful diagnosis connects hosting measurements with what visitors and the application were actually doing. A spike alone does not establish an attack or an immediate need to change plans. Find the workload involved before changing the website.
1. Place the problem in context
Record affected URLs, the time and time zone, then describe the action that fails: opening a page, searching for a product, submitting a form or using the administration area. State whether the problem is constant or intermittent and what changed recently.
Open your cPanel resource measurements for the same period. Keep a screenshot of limits reached and the available values. If several websites share the account, identify which were active: account measurements may not directly attribute the workload to one website.
2. Identify the resource involved
CloudLinux limits apply to different resources. CPU concerns processing, memory concerns active workloads, and IO/IOPS concern input/output. EP and NPROC relate to concurrent workloads or processes; they are not counts of unique visitors.
Occupied disk space, file counts and data transferred over the network are other measurements. Smaller images can reduce transfers without fixing an expensive database query. An HTTP error also does not identify the responsible resource or application by itself: use our HTTP error guide alongside the measurements.
3. Match the spike to an activity
Examine the possibilities that fit the observed times:
- Web requests: an advertising campaign, heavily used internal search, a dynamic page or automated visits. Compare requested URLs and their frequency rather than visitor totals alone.
- Scheduled work: an import, backup, image-generation task or catalogue synchronization. Check its start time and duration, not only the scheduled interval.
- Application changes: a new module, feature, update or cache configuration. Record the specific change and its time.
- Repeated failures: a task or integration may retry after an error. Look for the initial failure and subsequent attempts.
cPanel’s cron documentation explains that a new run can start before the previous one finishes. Do not disable every task as a test: some handle backups, email or business operations. Establish their purpose before intervening.
4. Gather useful evidence
Where your service provides them, access logs help identify received requests, while error logs show recorded failures. Check their time coverage and time zone. A recent view or partial log may not cover the entire incident.
A slow feature may also be waiting for a database or an external service. Ask the developer to examine that specific workflow; low CPU usage at one moment does not rule out a problem. A series of errors may be a consequence of the failure rather than its cause.
For WordPress, our performance and LiteSpeed Cache guide covers caching, plugins and personalized pages. If you suspect malicious activity, tell our team instead of immediately deleting files or logs that could help the investigation.
5. Choose a focused response with Nuagerie
Open a request through your Nuagerie client area with the domain, times, affected features, screenshots and recent changes. Share only relevant excerpts, without passwords, access tokens or customer data.
This information helps distinguish hosting checks from application work. Once the cause is clearer, follow our resource-reduction guide. If demand remains consistently high, we can also assess an appropriate hosting upgrade with you, based on actual use and your goals.
