Monitoring, Logs and Resource Usage in GreatHosts CP

1. Start with Server Information

Server Information gives the account a direct place to review the current server context. Use it before relying on assumptions copied from another hosting environment.

• Record relevant environment information when opening a support ticket.
• Do not assume every account has identical limits or software configuration.
• Re-check after a plan or platform change.

2. Enable and inspect access/error logs

The current Statistics area exposes Access & Error Logs. These are often the fastest way to distinguish a broken application route from a resource or DNS problem.

• Use error logs first for server-side failures.
• Use access logs to confirm whether requests are reaching the site.
• Avoid storing or sharing sensitive log content unnecessarily.

3. Web statistics

Web Statistics provides a site-level view of visits and usage. Treat it as operational context rather than as a substitute for a dedicated analytics platform when marketing attribution is required.

• Use it to understand broad activity patterns.
• Do not infer individual-user behavior beyond what the tool actually reports.
• For campaigns, use appropriate privacy-aware analytics separately if needed.

4. Traffic statistics

Traffic Stats helps identify transfer growth and unusually heavy usage. This matters when large assets, downloads or bots are consuming bandwidth.

• Compare traffic changes with deployments or campaigns.
• Optimize oversized assets before buying more infrastructure.
• Investigate abusive or unintended traffic separately from legitimate growth.

5. CPU statistics

CPU Stats exposes current server-usage levels for the account. Use sustained patterns—not one isolated spike—to decide whether the workload is outgrowing the current tier.

• Entry shared plans begin around the documented 5% CPU allowance, while some plans provide more.
• Short spikes can be normal.
• Sustained saturation together with slow requests is a stronger upgrade signal.

6. Diagnose before upgrading

A performance problem can come from inefficient code, database queries, external APIs, oversized media, bots, configuration or actual resource limits. Upgrade only after the evidence points to capacity or control.

• Check errors first.
• Check request/traffic patterns.
• Check CPU/resource trends.
• Optimize obvious application bottlenecks.
• Then decide between a larger managed plan, an add-on capability, semi-dedicated hosting or KVM.

7. Collect evidence for support

When provider support is needed, include the domain, time of the problem, action that failed and relevant error/log details. This is more useful than reporting only that a site is slow.

• Use timestamps and reproducible steps.
• Remove passwords, tokens and private keys from screenshots/log excerpts.
• State whether the problem is constant or intermittent.

Services related to this guide