Monitoring and troubleshooting
The Panel separates lightweight site status from heavier diagnostic operations so normal page loads do not repeatedly execute expensive checks on the hosting node.
Site status
Start with the current site state. Confirm that the site is enabled, assigned to the expected node and reporting healthy enough for the operation you are attempting.
If the site was recently moved, restored, imported or had hosting settings changed, verify the managed state reflects the intended destination and runtime before troubleshooting the application itself.
Logs
Use Logs when a request is returning an error, PHP is crashing, a plugin/theme action fails or the web server is rejecting a request.
Match the timestamp of the browser request to the relevant Nginx, Apache or PHP error entry. A PHP fatal error usually identifies the file and stack that failed; fix the application error before increasing limits unless the log explicitly shows resource exhaustion.
Access logs are also useful for request-path, status-code and client-address problems. When a CDN or reverse proxy is present, verify real-client-IP handling before relying on the apparent source address for security decisions.
Diagnostics
Use Diagnostics for deeper checks that should not run continuously. Diagnostic operations may query WordPress, PHP, MariaDB and the web stack directly.
Run the narrowest diagnostic that answers the question. Repeated broad diagnostics can add load to a site that is already under stress.
Cache diagnostics
When output appears stale, identify which cache layer is involved before purging everything:
- WordPress/plugin cache
- Webcore Nginx page cache
- Redis object cache
- browser or external CDN cache
For Webcore Page Cache, inspect the X-Webcore-Cache response header to distinguish HIT, MISS and BYPASS behaviour.
Repair and remediation
Use managed repair actions where available instead of manually changing ownership, permissions or configuration files on the node. Managed repair keeps the site's filesystem and runtime aligned with the state the Panel expects.
For malware-related symptoms, use the dedicated malware scan/remediation workflow rather than treating generic file repair as a security cleanup.
Troubleshooting order
- Confirm whether the problem affects one request, the whole site or the hosting node.
- Check site enabled/state, node assignment and SSL state.
- Inspect logs at the exact time of the failure.
- Identify whether page, object, plugin or external caching could explain stale output.
- Run the relevant diagnostic or managed repair action.
- Reproduce risky application changes in Staging where possible.
- Take a backup or snapshot before destructive repair work.
When Staging works but production does not
Compare DNS, SSL, production-only integrations, cache state, environment-specific plugin configuration and external services.
A successful staging clone confirms that the copied files and database can run in the isolated staging environment. It does not prove that production DNS, certificates, payment gateways, APIs, mail delivery or other external dependencies are identical.