ChatGPT or Claude Not Working? How to Fix 401, Network Error and Login Loop Problems

The 60-second test: is it an outage or is it my problem?

Open the vendor's official status page on a different device or network, then try the same chatbot in a private window. If the status page shows an incident for your service, wait. If it shows everything operational and a private window on another network works, the problem is on your side and the fixes in this guide will solve it. That single comparison separates the two cases in about a minute and saves you from clearing cookies, reinstalling apps and resetting passwords for a fault you cannot fix.

When ChatGPT, Claude, Gemini or Copilot stops answering, most people do the worst possible thing: they refresh ten times, then sign out, then reset their password. Each of those steps costs time, and the password reset can lock you out of an account you actually needed. A calm, ordered test is faster. This guide gives you that test, a decoder for the error messages you are most likely to see, and a list of fixes sorted from cheapest to most disruptive.

One honest limit before we start. This page is evergreen. It never tells you whether a particular service is down right now, because that changes by the minute and any article that claims it is out of date before you finish reading. The status pages below are the only source worth trusting for the live answer.

The reason this order works is that each step removes one whole category of cause. The status page rules the provider in or out. The phone on mobile data rules your home network and router in or out. The private window rules your cookies and extensions in or out. By the time you reach step five you usually know which of the three layers is guilty: the provider, your network, or your browser and account.

Official status pages worth bookmarking

Each AI vendor publishes its own status page, and that page is the authoritative source for whether a service has a known problem. Bookmark the one for each tool you use before you need it, because when the chatbot is down you may not remember the address. The pages below were opened and checked on October 1, 2026 to confirm what each one covers. We do not report their live state here on purpose.

Two practical notes. First, vendor addresses sometimes move. The Claude page, for instance, is reachable at status.claude.com, and older bookmarks to an Anthropic address may redirect. If a bookmark fails, search for the vendor name plus "status" and make sure you land on the vendor's own domain, not a lookalike. Second, status pages describe components, not your personal experience. A component can show green while one region, one plan or one feature misbehaves, so always read the component that matches what you use: web chat, mobile app, voice, login or API.

Crowd-reported sites such as Downdetector can be a useful second opinion, because they collect user complaints rather than waiting for the vendor to confirm a problem. Treat them as a hint, not proof. A spike in reports can come from a local internet provider problem or from a social media rumour, and a vendor-side fault can exist before anyone has clicked report. Official page first, crowd site second, your own test third.

The three layers where an AI chatbot can fail

Almost every "ChatGPT not working" or "Claude not responding" problem lives in one of three layers: the provider's servers, the path between you and them, or your own device and account. Knowing which layer you are in tells you whether to wait, to fix your network, or to fix your browser. The three layers behave very differently, and each leaves a recognisable fingerprint.

Layer 1: the provider

Provider-side faults affect many people at once. The fingerprint is that the status page shows an incident, that the same failure happens in every browser and on every device, and that it happens on your phone using mobile data too. Messages you tend to see are generic ones such as "something went wrong", "service unavailable" or "at capacity", along with server-side codes in the 500 range. You cannot fix these. You can only wait, switch to a fallback, and avoid retrying in a tight loop, which just adds load.

Layer 2: the path between you and the service

This layer includes your Wi-Fi, router, internet provider, DNS settings, VPN, proxy, and any company firewall. The fingerprint is that the status page is clean, other websites also feel slow or flaky, and the chatbot works on mobile data but not on your Wi-Fi, or the reverse. Messages are often "network error", endless spinners, or pages that load without their content. Our guide to fixing DNS probe errors covers the most common cause on this layer.

Layer 3: your browser, device and account

This is the most common layer for individual users. The fingerprint is that the chatbot works in a private window or in another browser but not in your usual one, or works on your phone but not your laptop. Typical causes are a corrupted cookie, an extension that blocks scripts, a wrong system clock, outdated software, or an account problem such as an expired plan or a usage limit. Messages include "unable to authenticate", login loops, blank pages and "conversation not found".

Before you start: three things not to do

Do not reset your password, delete your account or reinstall your operating system as a first reaction. None of these fixes a status-page incident, and the first two can lock you out of conversations and billing history you still need. Most chatbot faults clear with a handful of low-risk steps taken in the right order.

• Do not paste your password or login code into a "fix" you found in a comment or a video. Fake support pages for AI tools exist, and they target people who are already frustrated. Use only the vendor's own help centre, reached by typing its address yourself.
• Do not install a "chatbot fixer" or a free "unlocker" app. Those are a common route to malware. Our guide on malicious fake AI browser extensions explains how they behave.
• Do not spam the send button. Repeated retries can trigger a rate limit, which turns a short outage into a longer lockout on your side. Wait a minute between attempts.

With that done, the next section decodes the message you are actually looking at. Matching the message to its likely cause is faster than trying every fix in order.

Error decoder: what each message usually means

The wording of the error is your best clue. A 401 or "unable to authenticate" points at your sign-in or session, a 429 points at too many requests, a 5xx code or "something went wrong" often points at the provider, and "network error" points at the path between you and the service. The table below maps the messages people search for to the most likely layer and the first fix to try. Vendors change their wording, so treat the table as a guide to probabilities, not a guarantee.

401 and "Unexpected status 401" in detail

HTTP status 401 is defined in the web standards as "unauthorized", which in practice means the server did not accept the proof of identity that came with your request. In a browser chat, that proof is a session cookie or token. In a command line tool, an editor plugin or a script, it is an API key or an access token. When you see "Unexpected status 401" inside a developer tool, the tool is quoting the raw status it got back and has no friendlier text to show.

A 401 does not tell you why the credential was rejected. The common reasons are an expired session, a signed-out account in another tab, a key that was revoked or pasted with a stray space, a token that belongs to a different organisation or workspace, a system clock far from real time, or a proxy that strips the authorization header on the way out. It can also appear briefly when the provider's own login system has a fault, which is why the status page check comes first. If the status page is clean, assume the credential or the path to it and work through the fixes in order.

Do not confuse 401 with 403. A 403 usually means you are identified but not allowed to do that thing, for example a region, plan or permission restriction. A 401 means the server does not know who you are, or does not accept who you claim to be.

"Unable to authenticate" and login loops

These two symptoms share a root: the browser and the service cannot agree on a session. The service sets a cookie after you sign in. If the browser blocks it (strict privacy settings, a cookie-blocking extension, third-party cookie limits on a sign-in redirect), refuses it (wrong clock makes it look already expired), or deletes it (a cleanup tool or a "clear cookies on exit" setting), the next page sees no session and sends you back to sign in. The loop can look like the site's fault when it is a local setting.

The quickest test is a private window. If sign-in works there, one of your normal browser's cookies or extensions is guilty, and the targeted fix is to clear data for that single site instead of wiping the whole browser. Our guide to clearing the cache in every browser shows how to do it per site in Chrome, Edge, Firefox and Safari.

"Network error" in detail

This is the browser reporting that the request never completed. It does not say the provider is down. Typical local causes are a VPN endpoint that the service rate-limits or blocks, a DNS resolver that returns a wrong or stale address, a company proxy that cannot handle long-lived streaming connections, an antivirus web shield, or an ad blocker rule that matches one of the service's script addresses. Because chatbots stream their answers token by token over a long connection, networks that cut idle or long-lived connections can break the reply halfway through, which looks like a response that starts and then stops with a network error.

If your answers cut off mid-sentence only on one network (the office, a hotel, a school), suspect that network's proxy or firewall. If they cut off everywhere, suspect the provider or your plan limits.

429 and rate limits

A 429 is a deliberate "slow down" from the service. It can come from your own usage (many prompts in a short time, very large uploads, a heavy plan limit), from a shared IP address (an office or a VPN exit used by hundreds of people), or from an automated tool hammering the API in a loop. The fix is patience, not cleverness: stop sending, wait several minutes, then retry once. If you see 429 constantly on a paid plan, read the plan's usage limits on the vendor's help pages, because many plans combine a message allowance with a rolling time window.

"Something went wrong" and its cousins

This is the least informative message and the one most tied to provider problems, but not always. A single corrupted conversation can throw it while every other chat works. Test by starting a brand new conversation. If a new chat works and an old one fails, the old chat is the problem, and copying its important content out and starting fresh is the practical answer. If every chat fails and the status page shows an incident for the matching component, wait.

A simple decision flow for the first five minutes

Work in this order: read the message, check the status page, test a private window, test mobile data, then fix only the layer that failed. Never change two things at once, because you will not know which change worked. This section turns the test from the start of the guide into a flow you can follow without thinking.

1. Message mentions 401, authenticate, login or session: go straight to the private window test, then to the sign-in fixes in the next section.
2. Message mentions network, fetch, timeout or connection: go straight to the mobile data test, then to the VPN, proxy and DNS fixes.
3. Message is generic ("something went wrong") on every chat: check the status page, then wait 10 minutes before changing anything.
4. Message mentions 429 or limits: stop and wait; check your plan.
5. Page is blank: hard refresh, then disable extensions for the site.

If the same site works on one device and not another on the same Wi-Fi, the network is cleared and the broken device is your problem. If it fails on every device on your Wi-Fi but works on mobile data, your router, internet provider or DNS is the problem, and rebooting the router is a legitimate first step. If it fails on all devices on every network, the provider is the likely cause.

The fixes, in order from cheapest to most disruptive

Try these in order and stop as soon as the chatbot works. The first four take under two minutes and fix most browser-side faults; the later ones touch your network, clock or company settings and are worth doing only if the earlier steps failed. Each step says what it tests, so even a failed step tells you something.

Step 1: hard refresh

A hard refresh tells the browser to ignore its stored copy of the page and download everything again, which fixes blank pages and half-loaded interfaces caused by a stale script. On Windows and Linux press Ctrl+Shift+R (or Ctrl+F5). On a Mac press Command+Shift+R in Chrome, Edge and Firefox. In Safari, hold Shift while clicking the reload button, or use the Develop menu if it is enabled. It costs five seconds and changes nothing permanent. If the chatbot loads but the answer still fails, move on.

Step 2: try a different browser

If the chatbot works in another browser, your problem is inside the first browser's settings, extensions or stored data, not in your account, your internet or the provider. Use any second browser you have: Edge, Chrome, Firefox or Safari. Do not install a random new one from a search result; use the one that comes with the system. This single test removes the provider and the network from the list, so it is the most informative step after the status page.

Step 3: private or incognito window

A private window starts with no stored cookies and, by default, with extensions switched off, so it separates "my account is fine" from "my browser profile is broken". Open it with Ctrl+Shift+N in Chrome and Edge (Ctrl+Shift+P in Firefox), or Command+Shift+N on Chrome for Mac (Command+Shift+P in Firefox and Safari). Sign in from scratch. If it works, the culprit is a cookie or an extension in your normal profile, and steps 4 and 5 are your fix. Some extensions are allowed in private windows by choice; if you enabled that, disable them for the test.

Step 4: extensions and ad blockers

Ad blockers, privacy tools, script blockers, password managers and AI helper extensions can all block the scripts or requests a chatbot needs, and disabling them for the one site is the fastest way to test. Open your browser's extensions page, switch off everything, reload the chatbot, and if it works turn extensions back on one at a time until it breaks again. Many blockers have a per-site pause button, which is cleaner than removing anything.

While you are there, look at the list critically. An extension you do not remember installing, especially one promising "free ChatGPT access", "AI sidebar" or "unlimited prompts", deserves removal. Our article on malicious fake AI browser extensions explains why these are a real risk and how to review what you have.

Step 5: clear cookies and site data for that one site

Clearing data for just the chatbot's address removes a corrupted session without logging you out of every other website, which is why it beats a full browser reset. In Chrome or Edge open the padlock or settings icon next to the address bar, choose site settings, and select clear data (or open Settings, Privacy, Site settings, View permissions and data stored across sites, and search for the vendor name). In Firefox use the padlock, then clear cookies and site data. In Safari use Settings, Privacy, Manage Website Data. Then close all tabs for the site, reopen it and sign in again. You will need your password and possibly a verification code, so make sure you have them before you start.

Clear the cache for the site as well if a hard refresh did not cure a blank page. Our cache clearing guide covers every major browser.

Step 6: VPN, proxy and mobile data

Turn off your VPN and any proxy, then test again, because shared VPN exit addresses and corporate proxies are among the most common causes of "network error", rate limits and blocked sign-ins. A VPN sends your traffic through an address used by many other people. Services may rate-limit, challenge or block some of those addresses, and sign-in systems sometimes treat a sudden location change as suspicious. If the chatbot works with the VPN off, either switch to a different VPN server, use split tunnelling to exclude the browser, or leave the VPN off for AI tools when your threat model allows it. For the trade-offs read our guides on antivirus versus VPN and on how firewall, VPN and antivirus differ.

Also test with your phone on mobile data (switch Wi-Fi off). If it works on mobile data but not on your Wi-Fi, your home network, router or provider is involved. Restart the router, wait two minutes, and try again before changing any settings.

Step 7: date, time and time zone

Secure sign-in relies on timestamps, so a computer or phone whose clock is even a few minutes wrong can cause failed authentication, rejected tokens and certificate warnings. Set the date and time to update automatically and confirm the time zone is correct. On Windows: Settings, Time and language, Date and time, turn on both automatic options and use Sync now. On macOS: System Settings, General, Date and Time, set automatically. On iPhone and Android: turn on automatic date and time in the settings. A drained CMOS battery on an older desktop or a dual-boot setup can leave the clock wrong after every restart; if the time keeps resetting, that is a hardware item worth a technician's attention.

Step 8: update the browser or the app

An outdated browser or app can lack the security protocols or features a current sign-in page needs, so install pending updates for the browser, the operating system and the chatbot's own desktop or mobile app. In Chrome and Edge open the three-dot menu, then Help, About, and let it update and restart. In Firefox open the menu, Help, About Firefox. On the phone use the app store's update list. If the browser itself crashes or freezes while loading heavy pages, our guide to fixing Chrome crashes on Windows 11 goes deeper.

Step 9: DNS, antivirus web shields and the company firewall

If the chatbot fails on only one network, ask whether that network filters traffic: a DNS filter, a web proxy, a firewall with TLS inspection, or an antivirus that scans encrypted connections. TLS inspection means the security device decrypts and re-encrypts your connection using its own certificate. It can cause certificate warnings, break long streaming replies, and make sign-in pages fail, particularly on tools that do not trust the company's certificate. On a work laptop, the correct answer is to tell your IT contact the exact error, the time, and the address of the site, so they can allow it deliberately. Do not try to bypass a corporate control yourself.

At home, try a different DNS resolver or follow our DNS troubleshooting guide. Temporarily pause your antivirus web protection for a test (not for browsing in general) and see whether the error disappears; if it does, add an exception rather than leaving protection off. If a page shows a certificate warning, see our explanation of the "your connection is not private" error and never click through a warning on a sign-in page.

Step 10: confirm cookies are allowed

Sign-in often involves redirects between the vendor and an identity provider, so a browser set to block all cookies or to block third-party cookies aggressively can create the login loop. In your browser's privacy settings, make sure cookies are allowed for the chatbot's domain (add an exception rather than relaxing everything), and that any "clear cookies when I close the browser" option does not apply to it. If you sign in with Google, Microsoft or Apple, also check that pop-ups for the site are allowed, since the sign-in window often opens as one.

After each step, test with a short prompt. Keep notes of what you tried. If you reach step 10 without success, collect your notes and the error screenshot and skip to the "when to call a professional" section, because the next steps involve account recovery or network equipment.

Mobile app fixes (iPhone and Android)

When an AI chatbot app fails on a phone, test the same account in the phone's browser and on another network, then update the app, restart the phone and, only if needed, sign out and back in or reinstall. Phone apps keep their own stored session, separate from any browser, so a problem can live in the app alone. Work through these steps in order.

1. Switch networks. Turn Wi-Fi off and use mobile data, or the reverse. A captive portal at a cafe, hotel or airport (a Wi-Fi that wants you to accept terms first) blocks apps silently until you open a browser and accept.
2. Turn off the VPN or private relay for a test. A phone VPN, a private DNS setting or a content-filtering profile can block the app's connection. On iPhone check Settings, VPN, and any installed profiles. On Android check Settings, Network, VPN and Private DNS.
3. Check date and time. Make sure automatic date and time is on, as in step 7 above.
4. Update the app and the phone's operating system. Open the app store, look for pending updates, and install them. A major system update released recently can leave older app versions misbehaving until the app is updated.
5. Force close and reopen. Swipe the app away from the app switcher and reopen it. On Android you can also use App info, Force stop.
6. Restart the phone. It clears stuck network services and background processes.
7. Clear the app's cache (Android) or offload and reinstall (iPhone). On Android go to Settings, Apps, the app, Storage, Clear cache. Clearing storage as well signs you out. On iPhone use Settings, General, iPhone Storage, the app, Offload App, then reinstall; this keeps documents and data in most cases.
8. Sign out and sign back in. Make sure you know the sign-in method you originally used (email and password, Google, Apple, Microsoft) before you sign out. Using a different method creates or opens a different account, which is a frequent reason for "my chats are missing".
9. Reinstall as the last step. Download only from the official app store listing by the vendor's own developer name, never from a link in an ad or message.

If the app works on mobile data but fails on your home Wi-Fi, the router is the suspect, not the phone. Restart the router, check whether the other devices behave the same, and consider the DNS steps from the previous section.

Account-side checks that look like technical errors

Several errors that look like faults are actually account states: an expired payment, a plan limit, a workspace restriction, a security lock or a different account than you think. Check these before spending an hour on browser fixes. They are quick to confirm in the account or billing page.

• Usage limit reached. Many plans cap messages or heavy features in a rolling window. A limit notice normally says so, but an API or tool wrapper may show only a generic error code.
• Payment problem. A failed card renewal can downgrade a paid plan silently. Open billing and check status.
• Wrong account or workspace. People with a personal and a work account often sign in to the wrong one. Check the profile menu and the workspace selector.
• Security verification. A new device, new location or VPN can trigger an extra verification step. Complete it on a device you trust, using the vendor's own site.
• Organisation policy. Work accounts can be restricted by an administrator, for example blocking certain features or connections. If only some features fail, ask your admin before you troubleshoot.
• Two-factor problems. Codes depend on the clock of the phone generating them. Fix the time (step 7) and request a new code.

If you suspect someone else signed in to your account, change your password from the vendor's official page, sign out of all sessions if that option exists, and review your two-factor method. Our guide on spotting AI-generated phishing emails helps you recognise the fake "your account is locked" messages that arrive during outages, when you are most likely to click.

For developers and API users: generic checks for 401 and friends

For API calls and developer tools, a 401 almost always means the key or token was missing, malformed, expired, revoked or sent to the wrong endpoint, so verify the credential, the header and the base URL before suspecting the provider. The checks below are generic and apply to any AI vendor's API; always follow the vendor's own documentation for exact header names and endpoints.

1. Check the environment variable is really set in the shell or service that runs the tool. A key exported in one terminal is not visible to a different terminal, an IDE, a container or a scheduled job.
2. Look for invisible damage. Trailing spaces, line breaks, smart quotes or a copied prefix can corrupt a key. Re-copy it from the vendor's console and paste it into a plain text field.
3. Confirm the key matches the service. A key for one vendor, one project or one organisation will not work against another. Keys can also be limited by scope or permissions.
4. Confirm the key is still active. Keys can be deleted, rotated or disabled in the console, and some expire. Create a new one and test with the simplest possible request.
5. Check the base URL. A custom endpoint, a gateway or a proxy setting inherited from an old project can send your request to a place that does not know your key.
6. Check proxies and gateways. A corporate proxy can strip or alter headers. Test from a different network, or ask the network team whether authorization headers are preserved.
7. Check clock skew. Some signed requests fail when the machine clock is far off.
8. Differentiate 401 from 403, 429 and 5xx. 401 is identity, 403 is permission, 429 is rate, 5xx is the server. Do not retry a 401 in a loop; fix the credential first.
9. Log the response body, never the key. The error body from the vendor often names the exact reason. Redact secrets before sharing logs.

Treat API keys like passwords. Never paste them into chat windows, screenshots, public repositories or support tickets, and rotate any key you suspect has leaked. If a key appeared in a public place, assume it is compromised the moment it was published and replace it immediately.

Business continuity: what to do when the AI tool is down

Treat an AI chatbot like any other cloud service your team depends on: decide in advance who checks the status page, which fallback tool is approved, which tasks can wait, and what data must never be pasted into a substitute. A one-page plan costs an hour to write and saves a morning of scrambling. Many small businesses now use chatbots for drafting emails, summarising documents, writing code and answering customers, so an interruption has a real cost even when the cause is not yours to fix.

Choose the fallback before you need it

A fallback tool is only useful if the account already exists, the staff know how to use it, and your policy allows it. Signing up for a new service in the middle of an interruption, with a company email and a credit card, is how data ends up in tools nobody approved. Compare options calmly in advance with our ChatGPT vs Claude vs Gemini comparison, the broader four-tool comparison, and the two-way ChatGPT vs Claude guide. For a budget-conscious list, see best free AI tools. Pick one primary and one backup from a different vendor, because two tools from the same company share failure modes.

Make your work portable

The best protection against any outage is not depending on chat history. Keep the prompts that work, the style guides, the checklists and the final outputs in your own documents. Then any capable assistant, or a person, can pick up the task. The same habit protects you if an account is suspended, a subscription lapses or an employee leaves.

Know the manual route

For each AI-assisted task, write the manual version in two lines: for example, "customer reply drafts: use the saved templates in the shared folder", or "meeting summaries: the note-taker writes bullet points during the call". That turns an outage from a crisis into a slower afternoon.

Privacy hygiene when you troubleshoot and when you switch tools

Never paste passwords, API keys, client data or screenshots with personal information into a chatbot, a "fixer" site or a fallback tool you have not approved, and never give a login code to anyone who contacts you about an outage. Outages are when people hurry, and hurry is what scammers and careless habits exploit.

• Beware of outage-themed phishing. Emails and texts saying "your account is suspended, verify now" appear whenever a popular service has trouble. Go to the vendor's site by typing the address yourself.
• Do not search for the sign-in page and click the first ad. Fake lookalike sign-in pages are bought as ads. Use a bookmark.
• Do not install unofficial apps or extensions that promise a working version. See our warnings on fake AI extensions and on the wider risks of AI browser extensions.
• Sanitise screenshots before sending them to support or posting them in forums. Error screens can show your email, a workspace name or a key fragment.
• Use a different fallback for sensitive work only if policy allows it. A free consumer tool may handle data differently from a business plan. Read the vendor's data and retention terms before you trust any tool with client material.
• Turn on multi-factor authentication for every AI account. A stolen chatbot account exposes your chat history, which often holds more sensitive detail than people remember.
• Review which apps and connectors have access to your account, drive or mail, and remove those you no longer use.

If staff are using unapproved tools because the approved one failed, that is a policy gap, not a discipline problem. Read about shadow AI and how to write an AI usage policy for your business, which includes what to do during downtime.

Realistic scenarios (illustrative)

The three scenarios below are illustrative composites, not real client cases. They show how the 60-second test and the ordered fixes narrow a vague complaint to a specific cause. Times and amounts are examples.

Scenario 1: the login loop on one laptop

An accountant in a four-person office finds that her chatbot returns her to the sign-in page every time she signs in on her laptop, while a colleague's laptop on the same Wi-Fi works fine. The status page shows no incident. A private window works. She disables her ad blocker for the site and the loop continues, so she clears site data for the chatbot's address only, signs in again, and the loop stops. Total time: about six minutes. The cause was a corrupted session cookie from an interrupted earlier sign-in.

Scenario 2: "network error" only at the office

A small design studio sees "network error" about 20 seconds into long answers, only on the office network. Answers on mobile data are fine. The office router also runs a security feature that inspects encrypted traffic and times out long connections. The owner asks the installer to add an exception for the service, and long answers complete. The fix required a setting change by whoever manages the firewall; no browser fix would have helped.

Scenario 3: a script returns "Unexpected status 401"

A developer's nightly script that summarises support tickets starts failing with 401. The status page is clean. The key works when pasted into a manual test from a laptop, but the scheduled job runs under a service account that never received the environment variable after a server rebuild. Setting the variable for the service account solves it. The lesson: a 401 from automation is usually a configuration difference between where you test and where the job runs.

What this costs: DIY versus paying a technician (CAD)

Almost every fix in this guide is free and takes five to thirty minutes of your time. Paid help makes sense when the problem involves a company firewall, repeated account lockouts or a team that cannot work, and a single 60-minute remote consultation with IT Cares costs 119.99$ CAD.

The cheapest thing you can spend money on is not repair but preparation: an hour of planning your downtime routine usually costs less than one lost half-day for a team that cannot reach its tools.

Official resources

For the live answer and for exact, current instructions, use the vendors' own pages: their status pages for outages and their help centres for account, billing and error-specific guidance. We link them here so you can reach them without searching, which also avoids lookalike sites.

• OpenAI status: status.openai.com lists groups for APIs, ChatGPT components such as conversations, login, voice mode, file uploads and image generation, and Codex.
• Claude status: status.claude.com lists claude.ai, the Claude Console, the Claude API, Claude Code and related products, with email, SMS, Slack, Microsoft Teams, webhook and feed subscriptions.
• Google Workspace Status Dashboard: google.com/appsstatus/dashboard lists Gemini together with Gmail, Docs and Meet.
• Microsoft service health: status.cloud.microsoft is Microsoft's service status page. Administrators can also see service health in their Microsoft 365 admin centre.
• Vendor help centres: search for the vendor name plus "help centre" and confirm you land on the vendor's own domain.

We opened these pages while preparing this guide to confirm what they cover. We do not describe their current state, and you should not trust any article that does.

Common questions

The questions below cover what people most often ask when a chatbot stops working. The full answers are also in the FAQ section at the end of the article. If your situation is not covered, call us; it is faster than guessing.

• Is it down for everyone or just me? Use the 60-second test at the top.
• Why do I get 401 when my password is right? A 401 is about the session or token, not only the password.
• Will clearing cookies delete my chats? Chats are normally stored in your account, not in the browser, but confirm you can sign in first.
• Can a VPN cause these errors? Yes, see step 6.

When to call a professional

Call for help if the chatbot fails only on a work network, if you keep getting locked out of an account you need for business, if several staff are affected, or if you suspect a stolen account or a fake support contact. These cases involve equipment, policy or security, not a quick browser tweak. Stopping early is cheaper than a fourth round of password resets, which can make an account recovery harder.

IT Cares has provided remote and on-site IT support in Quebec and across Canada since 2014. In a remote session a technician can check your browser, network path, DNS, VPN and security software while you watch, identify which of the three layers is failing, and help you write the downtime plan from this guide. For a business, we can also review which AI tools your team uses and set up an approved fallback.

To talk to someone now, call 1 (888) 711-9428 or book a remote session. Have the exact error text, a screenshot with personal details blurred, and the list of steps you already tried ready; it shortens the call.

Frequently asked questions

Related guides

• ChatGPT vs Claude 2026
• ChatGPT vs Claude vs Gemini
• ChatGPT, Claude, Gemini and Copilot compared
• Best free AI tools
• Chrome keeps crashing on Windows 11
• How to clear the cache in all browsers
• Fix DNS probe finished bad config
• Malicious fake AI browser extensions
• Shadow AI: the hidden risk of unapproved tools
• How to write an AI usage policy

Sources and official references

Last verified: October 1, 2026

• OpenAI Status
• Claude Status
• Google Workspace Status Dashboard
• Microsoft service health status