Guides / How to tell if a service is down or it's just you

Last reviewed 5 Oct 2026

How to tell if a service is down or it's just you

A five-minute method from the helpdesk: run the checker, read the official status page properly, change one variable at a time, then decide.

Every outage ticket starts the same way: "is it down?" Nine times out of ten the honest answer is "not for everyone". The tenth time it really is the vendor, and you want to know within five minutes so you can stop rebooting laptops and start telling people. This is the method we used on an MSP desk with a couple of hundred client offices.

1. Ask a machine that is not on your network

Put the address or the tool name into the checker. It does two separate things:

• For any URL, it fetches the host from a datacentre. If the host answers, it is up from the internet's point of view, even if it will not load for you.
• For a tool we watch (Outlook, Okta, Slack, Stripe and so on), it shows what the vendor's official status feed said at our last refresh, about every five minutes.

Read the verdict literally. Reachable means the host answered. Blocked the checker (a 403 or 429) means the host answered and refused a datacentre visitor; that is bot protection, not downtime. Server error means the host answered with a 5xx, which is a real fault on their side. Unreachable means no answer at all: DNS failed, the connection timed out, or the domain is dead.

2. Read the official status page properly

Status pages are honest but slow. Vendors usually post after their own engineers have confirmed a problem, which can be fifteen to thirty minutes after your phones start ringing. While you wait, read what is there:

• Component. "Exchange Online" is not "Teams". "Stripe Checkout" is not "Stripe Terminal". Match the component to what is actually broken.
• Region or cell. AWS names regions such as us-east-1. Okta names cells. An incident in a region you do not use is somebody else's morning.
• Tenant-scoped incidents. Microsoft 365 posts many incidents only inside the admin centre's Service health, not on the public page. If you are an admin, look there before you decide "it's just us".

3. Change one variable at a time

This is where most tickets get solved. Change exactly one thing, test, then change the next:

1. Browser. Private window, or a different browser. If that works, it is cache, cookies, an extension, or a signed-in profile from the wrong account.
2. Device. Same account on a phone. If the phone works on the same Wi-Fi, the PC is the patient.
3. Network. Phone off Wi-Fi, on mobile data. If mobile data works and the office does not, it is the office line, firewall, DNS or a filter.
4. Account. A colleague signs in on your machine, or you sign in on theirs. If only your account fails, it is licence, MFA, a lockout or permissions.
5. Location. Ask someone in another office or at home. If they are fine and the whole of your site is not, it is your site.

4. Look upstream

Lots of tools sit on the same few providers. A big AWS, Azure, Google Cloud or Cloudflare incident can make several unrelated tools wobble at the same minute. If three different SaaS products failed together, check the cloud before you check each vendor. Each of our service pages lists the upstream providers we watch for that tool.

5. Decide, and say it in one sentence

• Down for everyone: checker shows server errors or unreachable from outside, and/or the vendor has posted. Stop troubleshooting PCs, tell people, use the workaround.
• Down for your site: works on mobile data and at home, fails in the office. It is the office network. See why a site works for everyone else.
• Down for one person: works for colleagues on the same network. It is their device or their account.

When to escalate

Raise it with the vendor when you have proof from at least two networks and two accounts, and the official page is still quiet after twenty minutes. Give them the time it started (with time zone), what fails, what still works, and any error code. Escalate internally straight away if money or safety is involved: tills, payroll, or anything clinical. Do not wait for a status page to give you permission to use the fallback.

Related status pages

• Amazon Web Services
• Cloudflare
• Microsoft 365

Related guides

• Why a site works for everyone else but not me
• VPN connected but no internet or can't reach internal sites
• Slack not loading: is AWS down?
• Microsoft 365 sign-in loop or 'More information required'

FAQ

Why does the checker say a site is up when it won't load for me?

Because the host answered our request from a datacentre. Your path to it is the problem: DNS, your ISP, a work or school filter, a broken browser profile, or a country block. Try another network and a private browser window.

How long does it take a vendor to post an outage?

It varies. Many vendors confirm internally before posting, so a gap of fifteen to thirty minutes between the first user reports and the first status post is common. A quiet status page in the first few minutes is not proof that everything is fine.

Is a 403 or 429 error an outage?

No. Both mean the server answered and refused the request, usually bot protection or rate limiting. We label it 'Blocked the checker'. A 5xx error or no answer at all is what points to a real outage.

Do you show user-reported outages?

No. We only repeat official vendor status feeds and our own URL check. We do not graph user reports or invent a green light when a feed fails.