# Is the failure in the site or in the hosting > Before looking for what to repair, you need to know who to talk to. An incident belonging to the hosting will never be fixed in the code, and an application fault will never be solved by a support ticket. This page gives the method I apply first, before even asking for access: it takes minutes and saves days of blame passing. - Source canonique : [https://allaux.fr/en/problemes/site-ou-hebergement-d-ou-vient-la-panne](https://allaux.fr/en/problemes/site-ou-hebergement-d-ou-vient-la-panne) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Drop a test.html file with one line of text at the site root and open it: if it displays, DNS and the web server are fine and the fault is in the application. Add an info.php calling phpinfo() to confirm PHP is running, then delete it at once. If both respond, host support has nothing to fix: the cause is in the code, the database or the CMS configuration. ## The exact boundary between the two Hosting is the machine, the web service listening on it, the database service, disk space, resource limits and the network path to you. The site is what runs on top: the CMS, its modules, its theme, its configuration files, its data. The simplest rule is this: if the server returned anything at all, the hosting is working. An error page, a CMS message, a blank page, a half-built page: all of these mean a machine received the request and sent a response. The problem is then in the application in the vast majority of cases. Conversely, no response at all, a message written by the browser itself, or a page generated by the host are signs of an incident upstream of the site. ## Five observations that settle it 1. **Read who is speaking** — A message in the browser’s own styling comes from the browser. A message with the host’s logo comes from the host. A message in the site’s colours comes from the site. Trivial, and yet the most reliable clue there is. 2. **Test an address that does not depend on the CMS** — Drop a text file at the root, or open an existing image directly. If that file loads while pages fail, the web server is perfectly operational: the failure is in running the site. 3. **Compare the public side and the admin** — If one answers and the other does not, hosting is ruled out: both go through the same server, the same disk and the same database. 4. **See whether another site on the account works** — When several sites share the same hosting, one down points at that site; all down points at the machine or the account. 5. **Check consistency over time** — A failure coming and going every few minutes suggests a resource limit, so hosting. A stable failure, identical on every attempt, suggests code. ## What belongs to each side - Hosting: stopped machine, disk or database quota reached, suspended account, changed PHP version, a firewall blocking an address, network outage, a certificate not renewed by the panel. - Site: incompatible module, faulty override, stale compiled cache, over-heavy query, incorrect configuration file, inconsistent data after an import. - Shared ground: file permissions, scheduled tasks, mail sending, address rewriting. These four depend on both at once, and that is where most days are lost. ## What I ask a host, and what I do not > Asking "is everything fine on your side" always gets the same answer. Asking instead for the server error log extract for a precise time window, the account’s processor and memory usage over seven days, and the PHP version actually active for the website and for the command line gives verifiable material. Those three items always exist and settle the question. ## When the answer is "both" Some incidents genuinely are mixed, and that is where method matters most. A site consuming too much runs into a hosting limit, but the cause is a badly written query. Failing mail involves both the server configuration and the CMS settings. A PHP version change decided by the host breaks a module that was out of date. In those cases, raising the resource makes the symptom vanish without touching the cause, and the problem returns months later. Fixing the code without adjusting the limit sometimes leaves too little headroom for peaks. The right approach is to measure first, then decide what is a setting and what is a correction. I work alone and I act on both sides: I read the code as well as the server logs. That removes the back and forth between a developer blaming the hosting and a support desk blaming the site. ## Carry on with the right page - **My site is completely unreachable** — If nothing loads: the four checks to make before calling anyone. ([/problemes/site-ne-repond-plus](/problemes/site-ne-repond-plus)) - **502, 503 or 504 errors** — If an intermediary returns a code while the site stays silent: which link failed. ([/problemes/erreur-504-et-delais-depasses](/problemes/erreur-504-et-delais-depasses)) - **My host has sent me a warning** — If the message comes from hosting: quota, disk, processor, locked database. ([/problemes/avertissement-de-l-hebergeur](/problemes/avertissement-de-l-hebergeur)) - **My site slowed down overnight** — If the site answers but badly: separating a server slowdown from an application one. ([/problemes/site-lent-depuis-hier](/problemes/site-lent-depuis-hier)) ## FAQ ### My host says the problem is my site. How do I check? By asking for the server error log over the relevant window. If the lines name a file of your site, they are right and the file is identified. If the log holds nothing at that time, the request never reached the web service, and the answer runs the other way. ### Can a developer act on the hosting? On shared hosting, within the limits of the panel: PHP version, scheduled tasks, certificates, visible quotas. On a dedicated or virtual server the work is unrestricted, but it assumes administrator access explicitly handed over. ### Should I change host after an incident? Not as a reflex. One isolated incident says nothing about a service; a documented pattern does. And if the cause was in the application, moving hosting carries the problem along without solving it. ### How do I know whether the outage affects everyone or just me? Test from a mobile connection, with no corporate network and no VPN, and from another device. A local firewall or an address blocked by the server produces exactly the same screen as a general outage. ### What should I send for a fast diagnosis? The exact message shown, the start time, the address concerned, and access to the hosting panel. With those four, the site-or-hosting question is settled with no further exchanges.