Use timestamps, status codes and request paths to identify the failed layer before changing DNS, PHP or application settings.
Applies to: Web Hosting troubleshooting
Troubleshooting is fastest when you identify the layer that failed: DNS, TLS, web server, PHP, application, database or local device. Record exact error text and timestamps before changing configuration.
Before you start
- Sign in to the Customer Portal and open the affected hosting service.
- Take a current backup before changing website files, databases, DNS or application configuration.
Work through these checks
- Reproduce the problem once and record the exact UTC time, domain, URL, device and result.
- Open the access log and find the matching request, noting status code, method, path, response size and user agent.
- Open the error log for the same second and identify PHP fatal errors, permission failures, missing files or upstream timeouts.
- Group repeated requests by path or source when investigating abuse or resource use.
- Redact query-string secrets, personal data and authentication tokens before sharing log excerpts.
- Apply the smallest correction and repeat the same request to compare the new log result.
Confirm the result
- The intended hostname loads over HTTPS from a private browser session and serves the correct website.
- Forms, database-driven pages and the administration area work without a new PHP, permission or redirect error.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| The login page keeps rejecting the details. | The wrong email address, an old password, browser autofill or an account-specific lockout is being used. | Type the account email manually, use the password-reset process once and avoid repeated attempts that may extend a lockout. |
| A one-time code is not accepted. | The device clock is inaccurate, the code belongs to a different account or an older code was entered. | Set the device time automatically, wait for a fresh code and confirm the authenticator entry name before trying again. |
| The problem started immediately after a change. | A deployment, plugin, permission, PHP or configuration change introduced the fault. | Roll back only the last known change, clear caches and retest before making a second change. |
| The fault is intermittent. | Resource limits, traffic spikes, remote dependencies or scheduled work may be involved. | Record exact timestamps and compare them with CloudLinux usage, application logs and the Service Status page. |
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The affected domain and SiteWorx account
- The exact error text and time
- The last change made
- Relevant log lines with passwords and personal data removed
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- View website and error logs
- Fix a 500 Internal Server Error
- Fix a 403 Forbidden error
- Fix a 404 Not Found error
- Website not loading after a DNS change
Last reviewed: 2026-07-18.
