Why Is My Website Down: Is It Just You, or Everyone?

It is Saturday evening, you typed your own address into your phone to check something, and nothing came up. Maybe a browser warning, maybe a spinning wheel that gave up, maybe a page of grey text that means nothing to you. The person who built the site is not answering. You do not know whether the site is down, your Wi-Fi is down, or you did something last week that broke it. Every result for this search is a checker that tells you whether the site loads from somewhere else, which is useful, and then leaves you exactly where you were. Here is the order a calm technician would take, starting with the two free tests that split your problem from everyone's, and ending with the line where owner checks stop and repair starts.

A site can be unreachable from your desk while the rest of the world sees it fine. Your office router, a cached address on your laptop, or a security filter on the shop Wi-Fi can each block one building and nobody else. A site can also be down for everyone because the domain no longer points anywhere, the server is not answering, or the application behind it has failed. Those are different emergencies with different fixes, and the first job is to work out which one you have.

The test costs nothing. Turn off Wi-Fi on your phone and load the address on mobile data. Then send the address to somebody who is not in your building and ask them to try. If both of them get the site and you do not, the problem is local to your network and your customers are almost certainly still being served. If neither of them gets it, the outage is public. Try both versions of the address while you are at it, the one with www and the one without, because they can fail separately.

Google treats availability as its own diagnostic question, and its Search Console reports show when its crawler could not reach you. That report is for later. Right now the only question is whether a stranger on a different network can load your homepage.

Before you change a single setting, take a screenshot of exactly what the browser shows, and write down the time, the device and the network. A technician can narrow the cause from that one image faster than from any description, and the message on screen usually points at one layer of the stack.

The message can narrow the layer but cannot tell you why that layer failed. A domain error might be an expired registration, a deleted DNS zone or a typo in a record changed last week. A certificate warning might be an expiry or a certificate being served for the wrong address. The screenshot buys you a head start, and the checks in the next two sections do the rest.

There is a short list of things you can check tonight, with your own logins, that are safe because none of them changes anything. Work through it in this order.

• Test in a private browser window: it rules out a stale copy of the page on your own machine, and takes ten seconds.
• Open your domain registrar account: look for an expiry date that has passed, a suspension notice, or an unpaid renewal.
• Open the billing page of every web service you pay for: a declined or expired card is one of the quietest causes there is.
• Look at the certificate's dates in the browser: clicking the padlock or the warning shows when it expired, if it did.
• Check the inbox the domain is registered to: renewal reminders go there, and it is often an old address nobody reads.
• Write down what changed recently: a plugin update, a new theme, a renewal, a card swap, a DNS edit by somebody helping with email.

The step people skip is the registrant inbox. ICANN requires accredited registrars to send at least two reminders before a domain expires, roughly a month and a week beforehand, and one more within five days after expiry if nothing has happened, according to its expired-registration policy page. Those notices go to the email address on the registration record. If that address belongs to a former employee, a previous designer, or a mailbox that filled up in 2023, the warnings were sent and nobody saw them.

A large share of weekend outages come down to four things that are not dramatic and are not anyone's fault in the way a hack would be. Each has a signature, and each can be confirmed or ruled out from an account dashboard.

A lapsed domain. The site and the email both stop, usually at once. The registrar account will show the expiry, and ICANN's policy page says a registrar may offer an auto-renew grace period of between 1 and 45 days, though it is not required to. After that comes a redemption period with its own fee, and after that the name can be deleted and registered by somebody else.

A failed payment. Hosting and platform accounts suspend for non-payment, sometimes after a warning email to an address nobody monitors. The dashboard will say so. The fix is a card and a few minutes, and it is one of the few outages an owner can genuinely resolve alone.

An expired certificate. A certificate is valid until its expiry date unless revoked, as the Let's Encrypt glossary puts it, and the browser shows the date. Renewal is normally automatic on a modern setup, and when the automation breaks the first sign is a warning page for every visitor. Renewing it also needs a check that the right certificate is being served for the right address.

A DNS change still propagating. If somebody changed nameservers or DNS records in the last two days, some visitors will see the old destination and some the new one, and that is normal. Amazon's Route 53 documentation says resolvers can keep old nameserver data for 24 to 48 hours and that there is no way to speed that up. A record change inside an already-delegated zone usually takes effect in under a minute, so a slow one is a sign that the nameservers themselves moved.

If none of those four is the cause, you have done the owner's part of the job and it is time to hand over.

When a technician takes this on, the work follows a sequence, and it is worth knowing it so you can tell a methodical repair from guesswork. It runs roughly like this. Record the exact address, time and error. Reproduce it from an independent network, on both versions of the address. Check the registration record and the registrant contact. Check payment status on every relevant account. Compare the live DNS against what it is supposed to say, looking for changed nameservers, a deleted zone, or a missing record. Check the certificate's dates and the browser's specific warning. Check the provider's status page, the application logs, and every change made in the days before. Restore the smallest confirmed failure first, then test the public address again from outside, including the forms, the booking or checkout flow, and any email that depends on DNS. Then write an incident note: when it started, what caused it, what was done, and who owns each account.

The step that separates a good repair from a hopeful one is the second-to-last. One successful page load on one laptop proves one laptop can load it. The customer's task, the form, the payment, the confirmation email, needs testing separately.

Most of that sequence has no fixed duration because the cause sets it. A handful of timings are bounded by the sources, and it helps to know them so that a wait is recognisable as a wait rather than as somebody not working.

The Google figure matters more than it sounds. Its crawl-error troubleshooting page says a proper 503 response is treated as temporary, and that serving it for more than about two days can cause pages to fall out of the index. A site that has been showing an error for a week has a second, quieter problem starting behind the first.

The honest measure of the loss is the count of things that could not happen. For a service business that is calls that came from the site, direction requests, form submissions and consultations booked. For a shop it is product pages, carts and checkouts. For anything with a login it is failed sign-ins and the support load they create. The way to put a number on it is to take your own normal hourly or daily baseline for those actions, from your own analytics, call log and inbox, and compare the outage window against it.

That comparison is yours to make, because the vendor figures that circulate for downtime cost describe large companies and do not describe a business in Arlington with one site and one phone line. Keep the estimate honest too. Not every visitor who hit the error would have booked.

Search exposure is the second loss and it is measurable in Search Console, which shows when the crawler could not reach you and whether traffic moved afterwards. It is an exposure rather than a permanent penalty. A site restored within a couple of days is usually crawled again as normal. A site that stayed broken for longer may need pages re-crawled before they reappear, and Google does not promise when that happens.

Nobody can price a repair before they know which layer failed, because the range runs from a renewal you could have paid yourself to a security investigation with a restore from backup. A provider who quotes a fixed emergency price before looking is quoting for the average of those, which suits nobody. The scoped version is a diagnosis first, then a quote for the specific fix, with your approval before the work expands.

What can be priced are the components, and each one is a vendor's own number rather than a market rate.

• A .com renewal: GoDaddy's developer pricing table lists a standard renewal at $22.99 a year and a discounted auto-renewal at $14.99, per its published table in 2026. Every registrar prices differently, and promotions, contract terms and renewal method all move the figure.
• A redemption fee: if the domain lapsed past its grace period, GoDaddy's registration agreement says a redemption fee is likely on top of the renewal where recovery is available. Ask your own registrar for the exact figure before authorising anything.
• A certificate: $0 from Let's Encrypt, which describes itself as a free, automated certificate authority. The labour to fix a broken renewal is separate.
• Monitoring: optional, and not necessarily a purchase. Cloudflare's plan page lists a free tier at $0 and paid tiers at $20 to $200 a month billed annually in 2026, as an example of the range, not a recommendation. A calendar reminder and a monitored inbox cover a lot of ground for free.

The labour is the variable, and it varies by an order of magnitude between a card update and a compromised application. That is why the quote comes after the look.

Nothing in Arlington changes how a domain, a certificate or a server gets diagnosed. What changes is what an outage costs you on a particular weekend. The city hosted nine World Cup matches in 2026 and published business-readiness guidance ahead of them, and a restaurant, hotel or shop whose site went dark on a match day lost the evening's directions, hours and bookings at exactly the wrong moment. If your business has an event calendar, test the site in the days before the event, when a lapsed renewal is still a cheap fix.

The one legal rule worth knowing is narrow. Texas Business and Commerce Code Section 521.053 requires a business that owns or licenses sensitive personal information to notify affected people after a breach of system security, as quickly as possible and no later than the 60th day after determining the breach occurred, subject to the statute's own conditions. A site that is simply unavailable is not a breach. A site that is unavailable because somebody got into it and may have taken customer data can be, and at that point ordinary outage troubleshooting becomes a security investigation with a legal deadline attached. If the cause turns out to be unauthorised access, stop and get advice before doing anything else.

Prevention here is mostly ownership hygiene, and it is the kind of thing that gets done once and then never needs doing again. Put the domain's registrant contact on an inbox that at least two people can reach, and check it lands in that inbox by triggering a test notice. Keep a valid card on every account and a calendar entry a month before each renewal. Write one page listing the registrar, the DNS service, the hosting or platform, how the certificate renews, who pays each bill, the recovery email, the renewal dates, the nameservers, and where the backup lives. Then test the backup by restoring it somewhere harmless, because a backup that has never been restored is a hope.

Before any planned DNS or site change, record the previous values and allow for the caches. And keep the incident note from every outage, because the second one is nearly always a relative of the first.

How do I know if my website is down for everyone or just me?

Load it on your phone with Wi-Fi off, and ask somebody in another building to load it. If they see it and you do not, the fault is local to your network. If nobody sees it, the outage is public. A website down checker does the second half of that for you, but it cannot tell you why.

What causes website downtime most often?

For a small business site, an expired domain, a declined card, an expired certificate, a DNS change still propagating, a provider incident, or a change to the site itself in the days before. The first four can be checked from your own account dashboards without changing anything.

Why is my website not working when nothing was changed?

Something usually did change without a person touching the page. A renewal came due, a card expired, a certificate failed to renew automatically, a plugin updated itself, or a service you depend on had an incident. Check the account notices before assigning blame.

My site loads for me now. Is it fixed?

It is fixed for one device on one network at one moment. Test from an independent network, test both versions of the address, and test the thing a customer needs to do, the form or the booking, before calling it done.

Will being down hurt my Google ranking?

Google says it treats temporary errors as temporary and retries for about two days. Beyond that, pages can drop out of its index until they are crawled again. A short outage is usually fine. A week-long one may need pages re-crawled before they return, and Google does not promise when.

Should I pay for monitoring?

Not automatically. Monitoring notices a visible symptom and tells somebody, and that is worth paying for if a missed outage costs you more than the service does. It does not renew a domain, update a card or fix a certificate. A monitored registrant inbox and renewal reminders on a calendar prevent more outages than most alerts do.

The question you started with, whether the site is down or just your connection, is answered in two minutes with a phone and a colleague. The question behind it, why, is answered most of the time by four account dashboards you already have logins for.

What matters most is knowing where your part ends. Checking dates and notices is safe. Editing DNS, deleting a zone, moving the domain or clicking past a security warning while the cause is unknown is how a Saturday outage becomes a Wednesday one.

If you have done the checks, ruled out the boring causes, and the site is still dark, Arlington Website Designer hears about outages from businesses across Arlington, TX and the first thing we ask for is the screenshot. Send it, the address and what you have already checked through the contact page, and you will get back which layer failed, what fixing it involves, and a quote for that specific fix rather than for an emergency in general.