Published 11 November 2026
Intermittent downtime is a symptom, not a diagnosis. A website that fails on one device, through one internet connection or at one time of day may have a different cause from a site returning errors to everyone. Before changing hosting, record what failed, when it failed and what response appeared. That evidence helps you and your provider identify whether the issue is DNS, the server, PHP, the application, a database, resource limits or network connectivity.
Start by checking the site from another device and a separate connection, such as mobile data. Ask a colleague in a different location to test the same page. Note the exact time and time zone, URL, browser, connection and error text. Avoid repeated refreshes or making configuration changes while collecting the first observations.
First distinguish a site failure from a local problem
Try the home page and one simple, known URL, such as a contact page. Record whether the browser says it cannot find the domain, times out, shows a server error, or loads the page but reports an application problem. These are different clues. A browser message alone does not prove which component is responsible.
- One device or network fails: investigate local DNS caching, a VPN, firewall, browser extension or internet connection before assuming the hosting account is down.
- Several networks fail at the same time: check DNS and the web response, then collect timestamps for hosting support.
- Only one page or action fails: suspect a route, plugin, application function or database query rather than a complete loss of connectivity.
If you use command-line tools, save the complete output and the command used. A DNS lookup with nslookup or dig can show whether a domain resolves and which address is returned. Do not publish account identifiers or sensitive output when sharing results.
Use the error to narrow down the cause
DNS resolution failures
If the domain cannot be found or resolves inconsistently, compare its returned address from affected and unaffected networks. Check that the domain has not expired and that the authoritative DNS zone contains the intended records. If a recent nameserver or record change was made, record when it happened; cached answers may persist for the record’s time to live. Do not change nameservers or delete records as a test, because that can disrupt the website and email.
HTTP 5xx responses and connection timeouts
An HTTP 5xx status means a server-side component reported an error, but it does not by itself identify whether that component is the web server, PHP process or application. Record the exact status, URL and time. A timeout, connection refusal and an HTTP 503 are not interchangeable: the first two may occur before a normal HTTP response is received.
Check the hosting control panel’s available error logs for matching timestamps and messages. A log entry near the failure is more useful than a general report that the site was “down”. Do not assume every 5xx response requires a migration; configuration, application load or a temporary resource limit may be involved.
PHP or application errors
If the site loads but a particular page fails, look for PHP errors, recent code or plugin changes, and application logs around the recorded time. A blank page can also result from an error hidden from visitors. Keep public error display disabled on a live site; logs are safer for diagnosis. If you can reproduce the fault, note the steps without repeatedly submitting forms or placing test orders on a live store.
Database connection failures
Messages such as “Error establishing a database connection” point towards the application’s database connection, but the underlying reason still needs checking. Confirm that no recent configuration change altered the database name, user, password or host. Ask the provider to check relevant database service and account logs for the timestamp. Never send passwords in an ordinary support message.
Resource limits and network paths
Some hosting platforms impose account-level limits on processes, memory or other resources. A resource-limit message, a control-panel usage notice or a log entry is stronger evidence than guessing from a slow page. Record the time, affected URL and any limit notification, then ask support which limit was reached and what data supports that finding.
If the site works from some networks but not others, compare DNS answers and results over time. A route, local network, VPN, firewall or upstream connection may be involved. A single successful test does not rule out an intermittent problem; repeat checks at intervals and preserve failures as well as successes.
Collect a useful support report
- Describe the scope: list affected URLs, whether the problem affects the whole site, and which devices or networks reproduce it.
- Record evidence: provide timestamps with time zone, exact browser error or HTTP status, DNS lookup output, and relevant error-log lines.
- Give change history: note recent DNS, code, plugin, PHP, database or configuration changes, including when they were made.
- Protect private data: redact passwords, session tokens, customer details and payment information. Send logs through the provider’s recommended support channel.
- Ask a focused question: request a check of the relevant server, account limits or database logs for the supplied times rather than asking only whether the server is “up”.
Keep an incident record with both failed and successful checks. A pattern by time, page or network can be more diagnostic than a screenshot without context.
When migration may help—and when it will not
Changing hosting may be reasonable when repeated evidence points to a constraint or configuration that the current provider cannot address, the application’s requirements exceed the plan’s stated capacity, or the provider confirms an ongoing service issue without a suitable resolution. Before moving, compare the target environment’s PHP and database compatibility, resource policies, backup and restore process, email needs, DNS control and migration plan.
A migration is unlikely to fix an expired domain, incorrect DNS records, broken application code, a bad database credential, a device-specific fault or a network problem outside the hosting account. Those causes can follow the site to its new provider. Test a repair or obtain a clear diagnosis first where practical, and retain a restorable backup before any move.
For HostCupid customers and prospective customers, this evidence-first approach makes a support request or migration discussion more useful: HostCupid is a Chennai-based provider of shared, WordPress, reseller and master-reseller hosting, as well as migration assistance. A provider can investigate more effectively when the report identifies the affected URLs, timestamps and observed errors; no hosting change should be treated as a guaranteed cure without identifying the cause.
Sources
