Microsoft Lists cannot connect — diagnose connection errors

If Microsoft Lists shows a connection error or never loads, the cause is usually a transient Microsoft 365 service issue, a local sign-in or cache problem, or a network/tenant policy blocking access. Start by checking Microsoft 365 service health, then try reload and sign-out, an incognito browser, or Teams cache reset; advance to DNS/network tests and tenant policy checks if those don’t work. The steps below go from lowest-impact fixes to advanced diagnostics you can give to IT or Microsoft support.

I see a connection error or the Lists app won’t load — what does that look like?

Blank page in lists.microsoft.com or the Lists tab in Teams
A persistent spinning wheel with no content
An explicit message like “Cannot connect to Microsoft Lists” or “This page can’t be reached”
HTTP status codes shown in the browser dev tools: 401, 403, 404, 504 (or other 4xx/5xx) when loading Lists resources
A timed-out network request or CORS/blocked resource errors in the console

When this appears: it can be immediate after clicking Lists, after signing in, or after a network change (VPN, proxy). Reproduce quickly by loading https://lists.microsoft.com in a browser and opening the same List inside the Teams desktop app. If the browser shows a network error page or dev tools show blocked requests to Microsoft endpoints, follow the troubleshooting steps below.

Is this happening to everyone or just me? How to scope the problem fast

Product and versions this applies to: Microsoft Lists in a browser, Microsoft 365 web apps, Teams desktop and Teams web clients.

Privileges needed: none for the basic checks below. Admin access (Global Admin, SharePoint admin, or Azure AD admin) is required only for tenant-level checks described later.

Restart/backup: no restart or backup is required for the quick checks. Clearing cache or Teams local files is reversible but will sign you out of apps.

Quick, safe checks to do first:

1. Ask one or two colleagues to open https://lists.microsoft.com and the same list link.
2. Open an incognito/private window and sign in to https://lists.microsoft.com.
3. Open the Teams desktop app and the Teams web client at https://teams.microsoft.com and try the Lists tab there.

If multiple users on different networks see the same failure, suspect a Microsoft 365 service issue or a tenant policy. If only you see it and colleagues don’t, suspect local sign-in, browser cache, licensing, or device network settings.

Also check Microsoft 365 Service health quickly by signing into the Microsoft 365 admin center (Admin > Health > Service health) or ask an admin to check it. That confirms whether there’s a known outage affecting Lists or SharePoint services.

Fast fixes to try first (sign-out, reload, cache, and permission checks)

do these in order; they’re low risk and often resolve the issue.

Where to act: your device and browser or Teams client. Privilege: user.

1. Reload and sign out/in.
2. Click the browser reload button or press F5 to retry the page.
3. Sign out and sign back in to your Microsoft account via the browser profile menu.

Expected result: the Lists page loads after sign-in. If it doesn’t, move to the next step.

2. Try an incognito/private window and another browser.
3. Open a private window and go to https://lists.microsoft.com.

Expected result: if the private window works, the regular browser profile or extensions are the issue.

3. Clear browser cache and cookies for Microsoft sites.
4. In Chrome/Edge: Settings > Privacy, search and services > Clear browsing data. Choose Cookies and other site data and Cached images and files.

Expected result: cleared state should remove stale auth tokens; if Lists then loads, the cause was stale credentials or cached resources.

4. Clear Teams desktop cache.

quit Teams before clearing cache.

1. Quit Teams (right-click the Teams icon and select Quit).
2. Delete Teams local cache files.

%appdata%\Microsoft\Teams\Application Cache\Cache
%appdata%\Microsoft\Teams\Cache
%appdata%\Microsoft\Teams\IndexedDB
%appdata%\Microsoft\Teams\Local Storage

3. Restart Teams and sign in.

Expected result: Teams tab content rebuilds and Lists should render; if Teams still fails, cache was not the cause.

5. Check licensing and list/site permissions.
6. Confirm you have a valid Microsoft 365 license that includes SharePoint/Lists. If you’re not an admin, ask your admin to verify license assignment.
7. Verify list or site permissions by opening the underlying SharePoint site and checking Site permissions or the list’s settings.

Expected result: license and permission issues show as 401/403 responses in dev tools or a SharePoint permission-denied page; granting the correct license or permissions restores access.

6. Confirm conditional access prompts are not blocking sign-in.

• Complete any MFA or device compliance prompts shown during sign-in. If you see sign-in blocked messages, ask IT to check Azure AD sign-in logs for blocked attempts.

Network, DNS, proxy, and firewall checks that commonly block Lists

Where to act: your device and network. Privilege: user for basic tests; admin for changing proxy/firewall settings.

1. Basic hostname resolution and reachability tests.
2. Check DNS resolution for a key Lists endpoint.

nslookup lists.microsoft.com

Expected result: the command returns an IP address. If it fails, DNS is blocking or misconfigured.

2. Trace the route to the endpoint.

tracert lists.microsoft.com

Expected result: route completes to an external hop; if it times out early or shows a corporate gateway consistently dropping packets, a network device may be blocking traffic.

3. Test connectivity with a simple HTTP request (if curl is available).

curl -I https://lists.microsoft.com

Expected output: an HTTP response header such as 200, redirect, or 401. A network-level timeout indicates a connectivity block.

2. Check proxy and PAC files.

• On Windows, check Internet Options > Connections > LAN settings for a proxy or auto-config script URL (PAC). If a proxy is set, try a brief bypass (on a trusted network) to see if Lists loads without it.

3. Temporarily bypass corporate proxy/firewall to test.

• If your laptop supports a mobile hotspot, connect via the hotspot and retry https://lists.microsoft.com.

Expected result: if Lists loads on the hotspot but not on the corporate network, the corporate proxy or firewall is blocking required endpoints.

4. Required endpoints and ports (general guidance).

• Lists depends on Microsoft 365 services hosted on SharePoint and Office domains. Allow HTTPS outbound traffic (port 443) to Microsoft endpoints. If a firewall blocks outbound HTTPS to Microsoft endpoints or inspects/block TLS, Lists can fail to load.

If you determine the network is the culprit, capture traceroute/nslookup/curl output and escalate to your network team for firewall/proxy rule review.

Tenant and admin-level causes: conditional access, SharePoint site settings, and service configuration

Where to act: Microsoft 365 admin center and Azure AD. Privilege: Global Admin, SharePoint admin, or Azure AD admin.

1. Check Microsoft 365 service health.

• Admin center > Health > Service health.

Expected result: if there’s an active incident, the admin center will show affected services and recommended actions.

2. Review Azure AD sign-in logs for blocked authentication attempts.
3. Azure AD > Sign-ins. Filter by the affected user and time window.

Expected entries to look for: failed sign-ins, conditional access denials, or MFA failures. Record the correlation ID and the conditional access policy name if present.

3. Check Conditional Access policies.
4. Azure AD > Security > Conditional Access. Review policies that apply to the user or the Microsoft 365 apps.

Expected result: identify policies requiring compliant devices, trusted locations, or blocking legacy auth. If a policy blocks the session, modify the policy or create an exclusion only if allowed by your organization’s change process.

4. Inspect SharePoint tenant and site settings.
5. SharePoint admin center > Policies > Access control and Sharing settings. Check any restrictions that limit access by network location or unmanaged devices.
6. Open the specific site collection settings and check External sharing and Site permissions.

Expected result: if the tenant or site prevents the user’s access (for example, blocking unmanaged devices), you’ll see blocked access behavior in sign-in logs and SharePoint permission pages.

5. Licensing and usage reports.
6. Microsoft 365 admin center > Billing > Licenses and Users. Confirm license assignment and active service plans for SharePoint/Lists.

Expected result: missing or revoked license entries explain 401/403 errors; assigning the correct license resolves access denial.

If you find a blocking policy or log entries indicating conditional access denial, collect the policy name, sign-in entry (with correlation ID), and timestamp for escalation.

How to verify the problem is resolved and what to collect if you escalate

How to verify the fix worked:

1. Open https://lists.microsoft.com in the same browser and in an incognito window. The Lists home or the specific list should load without errors.
2. Open the same list inside the Teams desktop app and the Teams web app at https://teams.microsoft.com. The list content should render and actions (open item, edit, create item) should succeed.
3. Use browser dev tools (F12) Network tab while reproducing.

Expected network behavior:

• Resources load with HTTP 200 or expected redirects.
• No repeated 401/403/504 responses.

What to capture for escalation to IT or Microsoft support (collect these before logging a ticket):

• Screenshot of the error page and browser console/network errors.
• Browser dev tools Network capture: save a HAR file showing failed requests and their status codes.
• Traces and DNS output.

tracert lists.microsoft.com
nslookup lists.microsoft.com
curl -I https://lists.microsoft.com

• Teams logs (if issue occurs in Teams).

%appdata%\Microsoft\Teams\logs.txt

• Azure AD sign-in log entry (admin): timestamp, username, correlation ID, and the failure reason or conditional access policy name.
• Time (UTC), the username, impacted tenant ID, and a clear reproduction path (steps you took when the error happens). Include whether the issue occurs from other networks or devices.

Where to submit:

• Submit these items to your internal IT helpdesk first; if they escalate to Microsoft support, provide the HAR, logs, screenshots, and sign-in correlation ID in the support request.

Conclusion

If quick reloads, re-signing and cache clearing don’t fix Lists, test another network and an incognito window to narrow the scope. If the issue follows the tenant or matches a conditional access rule, ask an admin to check Azure AD sign-in logs, conditional access policies, licensing, and SharePoint permissions. Collect HAR, traceroute/nslookup/curl output, Teams logs and Azure sign-in correlation IDs before opening a support ticket.

Frequently Asked Questions

Why do I sometimes see a 403 when opening a list?

A 403 typically means you don’t have permission to access the resource. Check that the list or SharePoint site grants you access and that your Microsoft 365 license includes SharePoint/Lists. If permissions look correct, ask an admin to review Azure AD conditional access policies and sign-in logs for denied sessions.

Can a corporate proxy cause Lists to fail even though other websites work?

Yes. A proxy or firewall that blocks or inspects HTTPS traffic to Microsoft 365 endpoints can break Lists while other sites still load. Test by connecting through a different network (mobile hotspot) or bypassing the proxy temporarily; if that fixes it, provide traceroute/nslookup/curl output to your network team for firewall/proxy rule adjustments.