My website is not working, what is the reason

Most website outages start the same way. Somebody tries to open the site and gets a block of text instead of a homepage.

Service Unavailable: The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Additionally, a 503 Service Unavailable error was encountered while trying to use an ErrorDocument to handle the request.

You do not need to diagnose your own outage. This page explains what the error messages mean and what the sixteen causes are, so you understand what you are dealing with, and then it explains exactly what we do when you send us a domain and a screenshot.

What are the reasons for the website not working / down?

Website downtime traces back to one of sixteen causes. They are not equally likely, not equally urgent, and not equally quick to resolve. The list below sets out each one, what it usually looks like to a visitor, and what putting it right involves.

• Domain name expired. Site vanishes behind a parking page, and email usually stops too. Recovery gets harder over time.
• DNS misconfiguration. The name will not resolve, or it points at the wrong server or an outdated copy of the site.
• DNS propagation delay. The site loads for some visitors but not others, often by country. Confirming this saves time.
• Hosting plan expired. A suspension notice appears, or the site is simply gone. Provider and account must be settled first.
• Server down. Connections time out or are refused, and other sites on the same server are down too. Confirm the cause first.
• Cloud or network provider outage. The site is unreachable while other well known services struggle at the same time.
• Server cache serving stale content. An old version shows, or a fixed page still looks broken. Several layers can hold it.
• Server overload. Pages turn slow or intermittent, with 503 and 504 errors that worsen at busy times. Cause comes first.
• Server disk space full. Errors appear, uploads fail, forms stop saving and email bounces. Logs are usually to blame.
• Bandwidth exceeded. A limit notice appears, or the site fails late in the month and returns the next. Bots may cause it.
• Resource limits exceeded. Intermittent failures appear with no clear pattern, which is common on shared hosting.
• Expired SSL or TLS certificate. Visitors see a full page security warning, and most of them leave immediately.
• Platform security compromise. Defacement, spam pages, redirects or browser warnings appear on your own brand. Speed matters.
• Plugin or version auto update. The site breaks overnight with a blank page or 500 error, untouched by anyone.
• Plugin or software no longer supported. Features fail one by one, or suddenly break after a related update.
• Local network or device problem. Only you cannot reach the site while everyone else can. We confirm it from outside.

Two patterns explain much of what clients ask us about.

The most common causes are administrative rather than technical. Expired domains, hosting and certificates account for many outages. They are calendar problems, not engineering ones, and they happen when a renewal notice goes to an address nobody checks, to a former employee, or to an agency the business no longer uses.

The most damaging cause does not look like an outage. An expired certificate leaves the site running behind a full page security warning that many visitors read as a sign the company has been hacked. Few visitors click past it. Analytics still records the visits arriving, and the drop in enquiries can run for days before anyone connects the two.

Why is my website showing error message & how to solve

Website downtime is difficult to self diagnose for a specific reason: the symptom carries almost no information about the cause. An expired domain, a crashed server, a full disk, an expired certificate and a plugin update gone wrong can all present as a page that will not open. The visible clue is tiny and the possible causes are many.

That is why outages so often take days rather than hours. Not because any individual cause is hard to fix, but because the time goes on guessing, on changing settings that were not the problem, and on being passed between a hosting company, a registrar and whoever built the site, each of whom can only see their own piece.

Three things commonly make an outage longer and more expensive than it needed to be.

• Changes made while nobody knows the cause. Settings altered on a hunch create a second problem on top of the first, and now two things are wrong and nobody knows which happened when.
• Repeated reloading and retrying. If the cause is server overload or a resource limit, every attempt is another request the server has to refuse, and the pressure keeps the site down.
• Treating a symptom and stopping. A defaced page can be replaced in minutes while whatever allowed it stays in place. The site looks fine until it does not.

There is one thing worth doing before you contact anybody, and it takes ten seconds. Screenshot the exact error message on screen and note the time you saw it. Error messages change as caches clear and as people start making changes, and the original message plus a timestamp is the single most useful piece of evidence for diagnosis. Send both to us and you have given us a head start.

What does a 503 Service Unavailable error mean

A 503 Service Unavailable error means the server is reachable and running, but refusing to serve the page. That is better news than some alternatives, because the machine is alive and answering. Something on it is either too busy, deliberately switched off, or broken.

The three usual causes behind a 503 are a site genuinely left in maintenance mode, a server that has run out of capacity through traffic or hosting resource limits, or software behind the site that has crashed while the web server keeps answering.

The second line of that error message is the one that tells us most. When it says a 503 was also encountered while trying to use an ErrorDocument, the server could not even load its own custom error page. That points away from a simple maintenance flag and towards resource exhaustion or a crashed application, which is a different piece of work with a different urgency.

That distinction is the sort of thing that decides whether an outage is resolved in twenty minutes or drags on, and it is invisible unless you have read a few hundred of these.

What the common error messages mean

Error messages look alarming, but each one narrows the cause considerably. These are what the common ones tell us when a client sends one through.

• 503 Service Unavailable. The server is up but refusing requests, due to maintenance, overload or a crashed application.
• 500 Internal Server Error. The site's own code or configuration has broken, usually just after a change was made.
• 502 Bad Gateway. One server passed the request on and received nothing usable back, often from a proxy, cache or app.
• 504 Gateway Timeout. Something took too long, so the connection gave up. Slow queries are often the reason.
• 403 Forbidden. The server understood the request and refused it, usually through a permissions rule or a security tool.
• 404 Not Found. One page is missing while the rest of the site works. It needs a redirect or content fix, not outage work.
• DNS_PROBE_FINISHED_NXDOMAIN. The website name cannot be translated into an address. Check the domain and its DNS.
• ERR_NAME_NOT_RESOLVED. The browser cannot look up the site's name. The same domain and DNS checks apply here.
• ERR_CONNECTION_TIMED_OUT. The address resolves, but the server never answers. Server state and firewall rules come first.
• ERR_CONNECTION_REFUSED. The server actively rejected the connection, which points to its state or a firewall rule.
• Your connection is not private, ERR_CERT_DATE_INVALID. The security certificate has expired, and browsers warn visitors away.
• ERR_SSL_PROTOCOL_ERROR. The secure connection could not be set up. Check the certificate and server configuration.
• A blank white page with no error. The software ran, failed silently and returned nothing. Server logs hold the answer.

The blank page is the hardest version for an owner to act on, because nothing shows on screen and there is nothing obvious to search for. The information still exists, in server logs the site does not show you, and that is where the real diagnosis happens.

Why did my website break when nobody touched it

Websites break on their own more often than owners expect, and there are three real explanations.

• Something updated itself. Most platforms, WordPress in particular, can apply updates automatically. An update at two in the morning that conflicts with a theme or another plugin leaves a site that was fine at bedtime and broken at breakfast.
• A date passed. Domains, hosting and certificates expire on dates set long ago. Nothing changed on the day except the calendar.
• Something upstream changed. A host moved servers, a provider had an outage, a version of the underlying software was retired, or a third party service the site depends on stopped. Our write up of the Google Cloud outage and what it meant for UAE businesses shows how a failure far from your business takes your site with it.

The root cause is almost always the same. An unmaintained website is not stable, it is untouched, and those are different conditions. Software ages, dependencies are retired, certificates expire and disks fill, quietly, until one of them tips over. Which is the whole argument for having somebody watching it, and it is what our maintenance service exists to do.

Is my website down because it was hacked

Security problems deserve separate treatment because the stakes are higher and the response is different. A compromised site may not look down at all, which is why these run undetected for so long.

The signs are visible without any technical skill, and any one of them is worth reporting immediately.

• The site redirects somewhere else, often only on mobile, or only for visitors arriving from search.
• Pages you did not create appear in Google results under your own domain.
• A browser or search warning appears against your brand, which is the most damaging version because it reaches people who never visit the site.
• Enquiry forms stop delivering while still appearing to submit successfully.
• Your host suspends the account for sending spam you did not send.

The route in is rarely sophisticated. It is unpatched software, an out of date plugin, a weak password, or a known flaw in the technology underneath the site. Critical vulnerabilities in widely used web technologies are announced several times a year and affect sites whose own code is perfectly clean, because the fault sits beneath the website rather than inside it. The gap between a public announcement and automated scanning of the whole internet is measured in hours, not weeks.

This is the one category where acting on a hunch does real damage. Replacing a defaced page without finding the entry point leaves the door open. Restoring a backup taken after the compromise reinstalls it. Patching without checking for persistence leaves whatever was planted in place. Recovery work has an order, and getting it wrong means doing it twice. Our note on protecting your business online covers the wider picture, and if you are seeing any of the signs above, this is the point to contact us rather than experiment.

Why is my website not opening on mobile but works on desktop

A site that loads on desktop but not on mobile is usually not an outage, which is why this pattern causes so much confusion and so many unnecessary panics.

Four explanations cover nearly every case: the two devices are on different networks and one of those networks has the problem rather than the website; a mobile browser is holding an old cached copy of a problem that has already been fixed; the mobile version of the site is genuinely broken while the site itself is up, which is a development fault rather than a hosting one; or DNS changes from a recent move have reached one device and not the other.

The same reasoning applies to a site that fails in one browser while working in another, including the Chrome on Android version of this question. Google's own guidance on connection and loading errors groups the causes into device settings, device software such as a firewall or antivirus, network issues including the modem or router, browser issues including cookies, extensions and memory, and only then website issues. Four of those five are not the website.

What matters commercially is which of the four it is, because one of them means your mobile visitors cannot use your site and you may never hear about it from them. Checking the site from outside across devices and networks is part of what we do on any report, and it separates "your phone" from "your mobile site is broken" quickly.

What Tomsher does when you report a website down

Reporting an outage to us takes one message. What happens next is a defined sequence, and it is deliberately the same every time, because the fastest route to a cause is to rule things out in a fixed order rather than chase whichever theory sounds likely.

1. We confirm the outage from outside your network. Before anything else we establish whether the site is genuinely down or whether it is reaching you badly. That single answer decides everything that follows and it takes us moments.
2. We read the error and the server logs. The message on screen narrows the field. The logs behind it, which the site does not show you, usually name the actual failure, including on a blank page where there is nothing visible to go on.
3. We check the domain and DNS. Registration status, expiry, nameservers and the records behind them, because an expired domain or a wrong record produces an outage that looks exactly like a server failure.
4. We check the hosting and the server. Whether the account is active, whether the server is responding, and whether disk, bandwidth, memory or resource limits have been reached.
5. We check the certificate. Validity, installation and whether it is the certificate producing the warning rather than the site being down at all.
6. We check the software and recent changes. Platform and component versions, what updated and when, and whether an automatic update is the cause.
7. We check for compromise. Unexpected files, injected content, redirects and anything suggesting the outage is a symptom rather than the problem.
8. We tell you what is wrong in plain language. What it is, how urgent, what restoring it involves, and whether it needs your host, your registrar or us.
9. We restore it, and then we find out why. Getting the site back is the first job. Establishing why it happened and preventing a repeat is the second, and skipping it is how businesses have the same outage twice.

You do not need logins, documentation or technical knowledge to start this. A domain name and a screenshot is enough. Where access is needed we tell you exactly what to request and from whom, and in most cases we deal with those parties ourselves.

We deal with your hosting company and registrar for you

Dealing with providers is where most of the time in an outage is lost, and it is the part owners least want to do. A hosting support queue, a registrar whose account is in a former employee's name, and a developer who built the site three years ago each hold one piece of the picture and none of them holds the whole thing. The business ends up relaying technical messages between parties while the site stays down.

We take that over.

• We speak to hosting support in their own terms. A ticket that names the server, the error, the timestamps and the log entries gets a useful answer. A ticket that says the website is down gets a template reply and a day of waiting.
• We establish who holds what. Which registrar the domain sits with, which company actually hosts the site, who controls the DNS, and who has the logins. On older sites nobody internally can answer those questions, and finding out is frequently the real work.
• We handle recovery of access. Including the common situation where the domain or hosting account is registered to somebody who has left the business.
• We keep you updated in language you can forward. So you can tell your team and your customers what is happening without translating anything.
• We tell you when a provider is the blocker. Some causes can only be actioned by your host, and in those cases our job is to establish that quickly, escalate properly and stop you chasing the wrong supplier.

Knowing which supplier owns a problem, and being able to prove it to them, is most of what shortens an outage.

How Tomsher keeps websites from going down

Prevention is the half of this nobody sees, and the causes in the table above divide cleanly into ones prevented by a calendar and ones prevented by maintenance. Both are things we do for clients rather than things we expect them to remember.

• We track your renewal dates. Domain, hosting and certificate, so an outage never happens because a notice went to an address nobody reads.
• We apply updates and verify the result. Updates have to happen, because unpatched software is how sites get compromised. What breaks sites is an update applied automatically overnight with nobody checking the morning after. We check.
• We monitor from outside, and we monitor the enquiry form. So the first person to know your site is down is us, not a customer. A form that submits but never delivers is the most expensive silent failure a website has, and it never announces itself.
• We keep backups and we restore them. On a schedule, into a test environment, because a backup nobody has restored is a belief rather than a backup.
• We watch capacity before it becomes an outage. Disk, bandwidth and resource usage trend upward slowly and then fail suddenly. Seeing the trend is the difference between a planned move and an emergency.
• We tell you when the hosting no longer fits the site. Overload and resource limit failures usually mean the plan stopped matching the site some time ago, and we handle that move.

Our website maintenance and AMC service is where all of that sits, and our note on what a website AMC should include sets out what to look for in any contract, including ours. We also take over maintenance of sites built by other suppliers, which is a large part of what we do.

Why businesses call Tomsher when a website goes down

Tomsher Technologies has operated in Dubai since 2011, with more than 15 years of delivery experience, a fully in house team and a 4.9 out of 5 rating from 201 Google reviews. For outage work specifically, four things matter.

• We build, host and maintain, so nothing gets passed on. Development, hosting and support sit in one Dubai office. There is no handover between a company that built the site and a company that keeps it running, which is where accountability usually disappears during an outage.
• We work on sites we did not build. Including ones with no documentation, no original files and no record of who holds the hosting. You do not need to be an existing client to report a problem.
• A named person answers. Not a ticket queue and a hope, which matters more during an outage than at any other time.
• We tell you when it is not a problem worth paying for. If your site is up and the issue is at your end, we say so and charge you nothing for the answer. That happens often enough to be worth stating.

My website is not working FAQs

The questions we are asked most when a site goes down.

Why is this website not working?

From the outside almost every cause looks the same, which is a page that will not load, so the symptom tells you very little. The cause is usually one of sixteen things: an expired domain, DNS misconfiguration or propagation, expired hosting, a server that is down or overloaded or out of disk space or bandwidth, a cloud provider outage, stale caching, an expired SSL certificate, a security compromise, a plugin or software update that broke it, unsupported software, or a problem at your own end. Identifying which one requires access to the domain records, the server logs and the software, which is the work rather than the answer. Send us the domain and we will tell you.

How to fix if a website is not working?

The honest answer is that it depends entirely on which of sixteen causes it is, and that fixing the wrong one makes things worse. Changing settings on a hunch creates a second fault on top of the first. Repeatedly reloading a site that is failing on capacity keeps it down. Replacing a defaced page without finding the entry point leaves the door open. The one thing worth doing yourself takes ten seconds: screenshot the exact error and note the time, because that message changes as caches clear and people start making changes. Then send both to us and we will handle the rest, including dealing with your host.

What does a 503 Service Unavailable error mean?

The server is running and answering but refusing to serve the page. The three usual causes are a site left in maintenance mode, a server that has run out of capacity through traffic or hosting resource limits, or software behind the site that has crashed while the web server keeps responding. If the message also mentions a 503 encountered while trying to use an ErrorDocument, the server could not load its own error page, which points away from a maintenance flag and towards resource exhaustion or a crashed application. That distinction changes the fix and the urgency, and it is the sort of detail that decides whether an outage lasts twenty minutes or all day.

Why are websites not working right now?

If several well known services are struggling at the same time as your site, a cloud or network provider outage is the likely explanation, and nothing at your end will fix it. If only your site is affected, it is one of the other fifteen causes. The difference matters because the response is completely different: a provider outage is about communication and waiting, while a site specific failure is about diagnosis and repair. We establish which it is as the first step on any report, because getting that wrong wastes the most time.

Why do some websites not work while others load fine?

If one site fails and it fails for other people too, that site has a problem. If one site fails only for you while everything else works, something between your device and the internet is interfering with that specific address, such as a firewall, antivirus software, a VPN, a corporate or hotel content filter, a browser extension, or stored data from an earlier visit. Google's own guidance groups the possible causes into device settings, device software, network, browser and website, and four of those five are not the website. We check from outside your network so that question is settled in moments rather than argued about.

Web pages are not loading but my internet is fine, why?

Usually DNS, the service that translates a website name into a server address. The connection genuinely works, which is why messaging and email keep running, but the name lookup is failing. The other two common explanations are a network level block from a firewall, VPN or content filter, and a browser holding a broken stored copy of the page or an outdated certificate. DNS problems are also one of the easier causes to make worse by guessing, because records control email as well as the website, and a well intentioned change can take both down.

Why is my website not opening on mobile or Android when it works on desktop?

Four explanations cover nearly all of it. The devices are on different networks, so one network has the problem rather than the website. The mobile browser is holding an old cached copy of something already fixed. The mobile version of the site is genuinely broken while the site itself is up, which is a development fault. Or DNS changes from a recent move have reached one device and not another. The third of those is the one that matters commercially, because your mobile visitors cannot use the site and most will never tell you. We test across devices and networks as part of any report.

Why did my website break when nobody changed anything?

Three reasons, all common. Something updated itself, which on WordPress happens routinely and can apply an incompatible plugin or theme update overnight with nobody checking the result. A date passed, because domains, hosting and certificates expire on dates set long ago and nothing changed on the day except the calendar. Or something upstream changed, such as a host moving servers, a cloud provider outage, or a retired software version. An unmaintained site is not stable, it is untouched, and the two are different conditions. That is what a maintenance arrangement addresses.

My website shows a security warning instead of loading, what is that?

Almost always an expired SSL or TLS certificate, and commercially it is the most damaging version of a website problem precisely because the site is technically still up. Visitors meet a full page warning that most read as the company having been hacked, and very few click past it. Analytics keeps recording the visits arriving, so the problem can run for days before anyone links the drop in enquiries to it. Reissuing and installing a certificate correctly includes steps that are commonly missed, which is why the warning sometimes persists after a renewal that appeared to succeed.

How long will my website be down?

It depends on the cause, which is why identifying it first matters so much. A problem at your own end is minutes. An expired certificate or domain is often same day once the right account is reached, though a long expiry gets harder. A DNS change takes hours to reach everyone and nothing speeds that up. A server or cloud provider outage lasts as long as the provider takes. A compromised site takes longest, because restoring the visible damage is quick and finding how they got in is the real work. We give you a realistic answer once we know which one it is, rather than a hopeful one before.

Can you help if you did not build my website?

Yes, and it is a large share of what we do. We regularly diagnose and recover sites built by other suppliers, including ones with no documentation, no original files and no clear record of who holds the hosting or the domain. Working out what exists and where it sits is often the part nobody internally can answer, and it is where most of the delay in an outage comes from. You do not need to be an existing client, you do not need the logins, and you do not need to know what is wrong before contacting us.

What do you need from me to start?

The domain name, a screenshot of what you are seeing on screen, and roughly when it started. That is enough to begin. We do not need logins to diagnose most causes, because the domain, DNS, server response, certificate and software versions are all visible from outside. Where access is genuinely required, we tell you precisely what to request and from whom, and in most cases we deal with the hosting company or registrar directly on your behalf rather than asking you to relay technical messages.