Website Down? How to Distinguish DNS, Hosting and Website Errors

Map the failure before touching settings

A website request crosses several independent systems: the registered domain, authoritative DNS, the visitor's resolver, a network path, TLS negotiation, a web server and often an application with a database. A fault at any layer can look like a blank page. Write down the exact URL, local time and browser wording before trying fixes. Test the homepage and one known inner page separately. If email still works, that only shows the mail path may be healthy; it does not establish that the website's DNS or origin is correct.

Distinguish one visitor from a wider outage

Ask whether the error appears on one device, one office network, mobile data and an independent external connection. Compare results without logging into customer accounts on an untrusted device. A failure limited to one browser may involve cached redirects, extensions or local DNS; an outage seen across independent networks deserves server-side investigation. A single successful load also cannot prove all users are unaffected, because caches and geographically distributed routes differ. Record each test's network, hostname, timestamp and outcome rather than relying on a vague statement that the site is down.

Check registration and delegation separately

A registered domain and a working hosting subscription are different assets. Verify the registrar's domain status and expiration information through an authorized account or trustworthy registration lookup. Then check which nameservers the parent zone delegates to, not merely which DNS dashboard staff remember using. A renewal problem can affect the domain, while an active domain can still point at a cancelled server. Do not assume a registrar's expiration notice proves a website has already been deleted. Escalate ownership or billing questions to the authorized administrator without changing DNS as a first reaction.

Interpret DNS resolution errors accurately

Messages such as NXDOMAIN or ERR_NAME_NOT_RESOLVED suggest that the requested hostname did not resolve in the tested context. Check spelling, the exact subdomain, authoritative nameservers and the presence of appropriate A, AAAA or CNAME records. Compare answers from the authoritative source with one or more recursive resolvers. Cloudflare's DNS troubleshooting guide also explains negative caching: a resolver may remember that a newly created name did not exist. Repeatedly lowering a new record's TTL will not erase an earlier cached negative answer. Record the answers and remaining cache time before proposing changes.

Know what DNS can and cannot prove

A successful DNS lookup identifies an answer, not proof that a web application is healthy. If the hostname resolves to an address, the next question is whether the connection reaches the intended service. Compare the configured origin address with hosting records held by the authorized administrator, including IPv6 where applicable. A stale AAAA record can create different experiences for IPv6-capable visitors. With a proxied Cloudflare hostname, public DNS may return Cloudflare addresses rather than the private origin address; that is expected. Never publish a confidential origin IP merely to demonstrate a diagnostic result.

Separate network refusal from slow responses

A connection refused quickly differs from a connection that waits and times out. Refusal may indicate that no service is listening on the required port or that a network component rejects it. A timeout may involve packet loss, filtering, routing or an overloaded destination. Test the expected HTTPS endpoint rather than concluding from a successful ping; some healthy hosts do not answer ICMP. Keep raw timestamps and the requested hostname for the provider. Do not weaken firewalls or open ports broadly to make a single troubleshooting attempt pass.

Read the TLS certificate warning literally

A browser certificate warning may mean an expired certificate, hostname mismatch, untrusted issuer or another trust problem. Inspect the hostname, validity period and chain shown by a trusted diagnostic tool; do not ask staff to bypass the warning on a business login or payment page. Distinguish the visitor-to-edge certificate from the edge-to-origin certificate when a CDN is used. A padlock appearing on one hostname does not prove every subdomain is covered. Certificate renewal should be verified by a new handshake and by checking that the correct server presents the new certificate.

Recognise redirect loops without guessing

An ERR_TOO_MANY_REDIRECTS message indicates that the browser was repeatedly directed elsewhere. Inspect the redirect chain and note which hop repeats, whether HTTP changes to HTTPS, and whether the www hostname alternates with the apex. A proxy's TLS mode can interact with an origin's HTTPS enforcement; Cloudflare specifically warns that Flexible mode plus origin HTTP-to-HTTPS redirection can loop. Clearing cookies may help isolate a browser-specific problem but does not repair a server-side loop. Do not disable HTTPS or change security modes casually; plan a reversible configuration correction after identifying the cycle.

Understand the difference between 404 and 500

A 404 response means the requested resource was not found at that URL; it does not necessarily mean the whole server is offline. Check whether only a renamed product page or language path is affected. A 500 response indicates an internal server error, which may arise from application configuration, code or dependencies. Compare a static file, homepage and affected dynamic page. If static content works but checkout fails, prioritize application and database evidence. Keep error pages and status codes distinct from browser messages; a custom design can conceal the real status returned by the server.

Treat 502, 503 and 504 as different clues

A 502 Bad Gateway response usually means an intermediary received an invalid upstream response. A 504 indicates that an intermediary did not receive a timely response. A 503 means the server is temporarily unable to handle a request, for example during maintenance or overload. These labels guide investigation but do not identify a guilty supplier. Record which component generated the code and whether an upstream application was contacted. MDN and cPanel document the distinctions. Avoid treating all 5xx messages as proof that a hosting plan is too small; a broken deployment can produce similar symptoms.

Interpret Cloudflare 521 and 522

For a Cloudflare-proxied site, 521 means the origin refused Cloudflare's connection; an offline web service or blocking of Cloudflare addresses are documented possibilities. Error 522 means the connection to the origin timed out, which may involve routing, filtering, load or an outdated origin address. These are not interchangeable with a DNS NXDOMAIN result. Ask the hosting administrator to inspect service health and firewall evidence, preserving existing controls. Record the Ray ID if shown, the affected URL and the time zone. A browser screenshot without those details may not help the provider correlate logs.

Interpret Cloudflare 523 and 524

Cloudflare's 523 identifies an origin that is unreachable, so investigate the origin address and routing path with the network or hosting team. A 524 is different: Cloudflare connected to the origin, but the origin did not deliver an HTTP response within the applicable proxy timeout. A slow database query, export or exhausted worker pool may explain that second pattern. Compare the affected endpoint with a lightweight page before deciding to change infrastructure. Provider timeout settings and plan entitlements differ; do not promise that a particular timeout increase is available to every customer.

Interpret Cloudflare 525 and 526

Error 525 concerns a failed TLS handshake between Cloudflare and the origin under relevant encryption modes. Error 526 indicates that Cloudflare could not validate the origin certificate when strict validation applies. Inspect the origin certificate chain, hostname, expiry, TLS configuration and the listening HTTPS port through the authorized hosting team. These failures are distinct from a visitor's local certificate warning, even if both appear security-related. Avoid temporarily weakening strict certificate validation merely to hide the message; first identify and repair the certificate or server configuration, then verify the protected connection end to end.

Investigate a 520 without assuming a cause

Cloudflare describes 520 as an empty, unknown or unexpected response from the origin. Possible causes include a server crash, malformed response, unusually large headers or incompatible origin protocol behavior. It does not mean the CDN is necessarily at fault. Compare the edge status with the origin's own records and ask for correlation using the exact request time. If an origin log has no matching entry, consider intermediaries and cache behavior rather than declaring the application innocent. Changes to proxying, firewalls or protocol settings require controlled assessment because they can expose the origin or weaken protection.

Look for path-specific application failures

A site can serve its homepage while failing only on login, checkout, search or a Bahasa Melayu route. Test a representative public URL from each function without submitting real customer data. Note whether the fault occurs before or after authentication, and whether a POST request fails while GET pages load. Application errors can involve database connectivity, file permissions, missing environment variables or an incompatible plugin. A single failing feature is not proof that DNS needs changing. Give developers reproducible steps, anonymized request identifiers and the last known working release, not copied private session tokens.

Use logs as evidence, not a guessing game

Ask the authorized operator to correlate access logs, application errors, web-server events and infrastructure metrics for the same minute. A spike in 500 responses following a code release suggests a different investigation from rising connection timeouts during traffic growth. Compare CPU, memory, process limits, database connections and disk availability only where the hosting plan exposes reliable measurements. Preserve timestamps and time zones. Never publish raw logs containing addresses, tokens, personal information or request bodies. If access is restricted, give the provider a precise incident window and request a sanitized finding instead of demanding credentials.

Consider caching and edge-versus-origin differences

A CDN may serve a cached page while the origin is failing, or a cached error may remain visible after a repair. Compare cache status and origin status when those diagnostics are available. Test a safe uncached path with the administrator rather than indiscriminately purging everything. Different regions may reach different edge locations and receive different results. A successful cache hit proves the cached object was delivered, not that new form submissions or database writes work. Document the behavior of dynamic paths separately from static images and stylesheets; they have different availability requirements.

Check recent changes and define rollback conditions

Compare the first observed failure with recent releases, DNS edits, certificate renewals, firewall rules and provider maintenance notices. A change near the incident is a lead, not proof of causation. Ask which version or configuration is known to work and whether rollback would lose legitimate transactions or newer content. Verify backup freshness and database compatibility before reversing an application release. Record the exact condition that would trigger rollback and the tests required afterward. Never make simultaneous changes to DNS, TLS and application code: doing so destroys the ability to attribute the outcome reliably.

Keep business email out of website repair experiments

A business may host email and web pages under the same domain but on different systems. An A record or proxied web hostname is not interchangeable with MX records and mail authentication records. Changing nameservers to troubleshoot a website can accidentally replace the authoritative zone and disrupt email delivery. Inventory MX, SPF, DKIM, DMARC and other service records before any authorized DNS migration. If mail continues to arrive, preserve that evidence and avoid modifying its records. Separate website recovery from mailbox recovery in incident communications, because their impact and ownership can differ.

Prioritize a business-critical incident responsibly

For a Malaysian SME, a broken brochure page and an unavailable booking or payment workflow have different consequences. Record whether enquiries, customer support, transactions or published information are affected. Assign one incident coordinator to collect evidence and one authorized technical owner for each component. A temporary notice on an existing approved channel may be considered, but do not publish unverified recovery promises. Escalate suspected data exposure or account compromise through the applicable security procedure rather than treating it as ordinary downtime. The priority should follow actual customer impact, not merely the most dramatic browser error.

Understand the search visibility consequence

Persistent server errors can affect search crawling and indexing, but a short outage does not automatically erase all rankings. Google's crawler guidance says repeated 5xx responses can reduce crawling and eventually remove affected URLs if failures persist. Once service returns, verify that important pages give appropriate successful responses and that robots.txt remains accessible. Do not respond to a server outage by deleting pages from a sitemap or adding noindex without a separate reason. Track the affected URLs and recovery dates so future SEO analysis distinguishes a technical incident from content or demand changes.

Collect a useful provider escalation package

A concise support request should include the full failing URL, first and latest occurrence, time zone, browser message, HTTP or Cloudflare error code, and whether multiple networks reproduce it. Add the Ray ID when shown, plus a sanitized description of recent changes and relevant service identifiers through a secure support channel. Ask the provider which layer failed and what evidence supports that conclusion. Avoid sending passwords, private keys, full customer records or unrestricted logs in ordinary email. An actionable ticket helps separate registrar, DNS, CDN, hosting and application responsibilities without claiming a diagnosis that has not been demonstrated.

Verify recovery across the actual customer journey

A repaired homepage is not sufficient acceptance for a business website. Re-test the exact failed URL, key navigation, language variants, images, HTTPS, forms and any authorized enquiry or booking flow using non-sensitive test data. Compare results on at least two independent networks where practical. Confirm that the server is not returning a friendly-looking error page with an incorrect HTTP status. If an outage affected transactions, reconcile with the responsible system owner rather than replaying customer submissions blindly. Record the time of verified recovery and any unresolved intermittent behavior, then continue monitoring under the existing operating process.

Illustrative incident: homepage works, checkout fails

Imagine a hypothetical local shop whose homepage and product images load, but checkout returns 500 after a plugin update. DNS resolves consistently, the certificate is valid, and the static assets load from cache. Those observations make a broad DNS outage less likely, although they do not exclude every network problem. The useful next evidence is the checkout request ID, application error at the matching time and compatibility of the changed plugin. A controlled rollback might be appropriate after transaction and database risks are assessed. Buying a larger hosting plan without that evidence would be speculation.

Illustrative incident: different networks disagree

Consider a hypothetical business that can open its website on mobile data but not through its office connection after creating a new subdomain. The administrator confirms the record exists on authoritative nameservers, while the office resolver still reports NXDOMAIN. This points toward cached negative DNS information rather than a need to reinstall the website. Record the resolver and its remaining negative-cache lifetime, then retest after the relevant interval. If the authoritative source itself lacks the record, investigate the zone configuration instead. Neither observation justifies repeatedly switching nameservers or changing mail records.

Create a reusable diagnostic decision record

For each incident, preserve a short timeline: symptom, affected URL, affected networks, DNS answer, TLS result, HTTP status, origin or application evidence, change history, action taken and final acceptance test. Mark uncertain findings as hypotheses until corroborated. This record helps a future technician see whether a similar-looking error had a different root cause. Keep sensitive details in restricted systems and give customers only the appropriate service update. If you need help, ask the relevant domain, hosting or website administrator to interpret the evidence before authorizing changes. Troubleshooting is a sequence of tests, not a contest to change settings fastest.

Investigate an application slowdown before proposing a VPS

When a website repeatedly returns 503 errors during checkout or bookings, confirm whether PHP entry-process limits, memory exhaustion, a slow database query or an external payment service caused the incident. Keep the application logs, timestamps and affected workflow as evidence. Do not infer a VPS requirement merely from monthly website visitors or the amount of revenue.

OnHypp's normal Biz/Power packages serve ordinary email and website needs. They do not grant VPS root access and do not automatically provide application-specific support. Before migrating, confirm backups and rollback, test the affected checkout or portal workflow under load and protect the customer's existing email routing.

Sources & further reading

Ready to explore a related service?

See the related OnHypp service and decide whether it fits your business needs.

Email & hosting Domains Website design